Zašto se VPN otvorenog koda odbija u nabavci
Recenzent koji se protivi otvorenom kodu obično štiti zahtjev, a ne ukus za licencu. Pitajte koji, pa pripremite dokument koji mu odgovara.
Odbijanja koja se pozivaju na otvoreni kod rijetko zavise od licence. Recenzent obično štiti zahtjev: da neko održava objavljeno izdanje, da se instalirana gradnja može identifikovati, da procjena pokriva ono što se povezuje ili da se veza može povući. Rasprava koja slijedi obično odgovara na pitanje koje niko nije postavio.
Pitajte koji se zahtjev primjenjuje prije nego što branite licencu. Odgovor odlučuje koji vam dokument treba.
Oznaka nije zahtjev
Čitljiv izvorni kod znači da se objavljena implementacija može pregledati. To ne znači da ju je neko pregledao, da gradnja na mrežnom prolazu odgovara objavljenoj ili da održavalac duguje vašem postavljanju ispravku. Svaka od toga je zasebna tvrdnja sa zasebnim vlasnikom, a recenzent kojem treba jedna od njih neće biti zadovoljan ostalima. Glasno imenovanje tvrdnje obično je dovoljno da promijeni razgovor.
Obrnuta greška je jednako česta. Komercijalna licenca ne dokazuje da podrška pokriva funkciju na koju se oslanjate, da je procjena ispitala komponentu koju postavljate ili da će dobavljač poslati ispravku unutar vašeg servisnog prozora. Licenciranje opisuje uslove distribucije, dok se odluke o nabavci tiču pouzdanja. U oba slučaja licenca je najmanje informativan dio odgovora.
Držite klijenta i uslugu odvojeno. Revizija stolnog klijenta ne govori ništa o konfiguraciji partnerovog mrežnog prolaza, njegovom pružaocu identiteta ili načinu na koji njegovi operatori uklanjaju račune. Koje god dokaze prikupite, moraju odgovarati granici kojoj se od partnera traži da vjeruje.
Pretvorite zabrinutost u dokument
Zamolite odobravaoca da zahtjev izrazi u jednoj rečenici, pa navedite dokument koji bi ga zadovoljio. Nejasno umirivanje je ono što ove razgovore pretvara u raspravu o ideologiji.
| What the reviewer is protecting | Artifact that answers it | Who can sign it |
|---|---|---|
| The deployed release keeps getting fixes | Named maintainer, supported version list and the cadence for security releases | The operating team, with the maintainer's published policy attached |
| The build is the one that was reviewed | Package source, version string and the checksum or signature you verify at install | The team that builds or vendors the package |
| An assessment covers the right scope | Component and version assessed, findings raised, corrections made, retest date | Whoever performed the assessment |
| The access can be withdrawn | Identities granted, resources reachable, and the tested removal procedure | The service owner on the partner side |
NIST Secure Software Development Framework je ovdje koristan zbog jednog uskog razloga: uokviruje razgovore o nabavci oko zajedničkog rječnika praksi i komunikacije s dobavljačima. To podržava traženje definisanih dokaza umjesto rasprave o oznaci i nije certifikat koji prolazi bilo koji konkretan VPN.
Primijetite šta radi srednja kolona. Svaki red traži dokument koji ili postoji ili ne postoji, što mišljenje pretvara u isporuku koju neko može proizvesti ili odbiti.
Odvojite klijenta od usluge
Ugovor o podršci za klijentsku aplikaciju nije obaveza u vezi sa serverom do kojeg stiže vaš saobraćaj. Prije nego predstavite dokaze, označite koje dijelove puta upravlja partner, a koje vi upravljate u njegovo ime. Miješanje to dvoje stvara paket dokumenata koji izgleda temeljito i ne odgovara ni na šta.
Ako je postavljanje vaše, partneru možda treba vjerovati samo identitetu i pravilu pristupa, što je mnogo manji zahtjev od povjerenja u cijeli vaš lanac snabdijevanja softverom. Ako je postavljanje njegovo, klijent kojem dajete prednost može biti nevažan i konfiguracija mrežnog prolaza postaje tema. Utvrđivanje u kojem ste slučaju prije drugog sastanka štedi jedan ciklus pregleda.
Zatim provjerite operativna pitanja na kojima pregledi zaista padaju: ko uklanja račun, kako brzo i koji dokazi postoje nakon toga. Lijepo dokumentovana procjena bez procedure uklanjanja i dalje je otvoren nalaz.
Završite odlukom, a ne raspravom
Završite razmjenu pisanim ishodom: prihvaćeno izdanje, kontrole vezane za njega, imenovani operatori, dokazi koji još nedostaju i datum do kojeg se očekuju. Sve neriješeno treba zabilježiti kao uslov, umjesto da se upije u opštu izjavu o odobrenju.
Ako politika imenuje određeni odobreni proizvod, koristite put izuzetka umjesto izgradnje paralelnog aranžmana koji niko nije ovlastio. Uvjerljiv tehnički argument ne daje dozvolu, a nezvanično postavljanje je nalaz koji čeka da bude otkriven.
Ako se zahtjev zaista ne može ispuniti, prijeđite na odobrenu alternativu i recite zašto. Svrha vježbe je utvrditi na šta organizacija može računati, a jasno „ne“ je bolji ishod od odobrenja koje kasnije niko ne može braniti.