Proč se VPN s otevřeným zdrojovým kódem v zadávacím řízení odmítá
Recenzent, který namítá proti otevřenému zdroji, obvykle chrání požadavek, ne vkus v licencích. Zeptejte se který, a pak předložte dokument, který na něj odpovídá.
Odmítnutí, která se odvolávají na otevřený zdroj, málokdy závisí na licenci. Recenzent obvykle chrání požadavek: aby někdo udržoval nasazené vydání, aby bylo možné identifikovat nainstalovaný build, aby posouzení pokrylo to, co se připojuje, nebo aby bylo možné spojení odebrat. Následná debata obvykle odpovídá na otázku, kterou nikdo nepoložil.
Než začnete obhajovat licenci, zeptejte se, který požadavek platí. Odpověď určuje, který dokument potřebujete.
Označení není požadavek
Čitelný zdrojový kód znamená, že publikovanou implementaci lze zkontrolovat. Neznamená, že ji někdo zkontroloval, že build na bráně odpovídá publikovanému, nebo že vám správce dluží opravu nasazení. Každé z toho je samostatné tvrzení se samostatným vlastníkem a recenzenta, který potřebuje jedno z nich, ostatní neuspokojí. Vyslovit tvrzení nahlas obvykle stačí ke změně rozhovoru.
Opačná chyba je stejně častá. Komerční licence neprokazuje, že podpora pokrývá funkci, na kterou spoléháte, že posouzení prozkoumalo komponentu, kterou nasazujete, nebo že dodavatel dodá opravu v rámci vašeho servisního okna. Licencování popisuje podmínky distribuce, zatímco rozhodnutí o nákupu se týkají spolehnutí. V obou případech je licence nejméně informativní částí odpovědi.
Klienta a službu držte odděleně. Audit klientské aplikace pro počítač nic neříká o konfiguraci brány partnera, jeho poskytovateli identity ani o tom, jak jeho operátoři řeší odstraňování účtů. Jakékoli důkazy, které shromáždíte, musí odpovídat hranici, které má partner důvěřovat.
Převeďte obavu na dokument
Požádejte schvalovatele, aby požadavek vyjádřil jednou větou, a pak pojmenujte dokument, který by jej splnil. Právě vágní ujištění mění tyto rozhovory v debatu o ideologii.
| 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 zde užitečný z jednoho úzkého důvodu: rámuje rozhovory o pořizování kolem sdíleného slovníku postupů a komunikace s dodavateli. To podporuje žádost o definované důkazy místo hádky o označení a není to certifikace, kterou by prošla jakákoli konkrétní VPN.
Všimněte si, co dělá prostřední sloupec. Každý řádek žádá dokument, který buď existuje, nebo ne, což mění názor na výstup, který někdo může předložit nebo odmítnout.
Oddělte klienta od služby
Smlouva o podpoře klientské aplikace není závazkem ohledně serveru, ke kterému se váš provoz dostane. Než předložíte důkazy, označte, které části cesty provozuje partner a které provozujete vy jeho jménem. Smíchání obojího vytváří balík dokumentů, který vypadá důkladně a nic neodpovídá.
Pokud je nasazení vaše, partner možná potřebuje důvěřovat jen identitě a pravidlu přístupu, což je mnohem menší žádost než důvěra v celý váš dodavatelský řetězec softwaru. Pokud je nasazení jeho, klient, kterého preferujete, může být irelevantní a tématem se stane konfigurace brány. Zjistit, v jakém případě jste, před druhým setkáním ušetří jeden cyklus posouzení.
Pak zkontrolujte provozní otázky, na kterých posouzení skutečně selhávají: kdo účet odstraní, jak rychle a jaké důkazy potom existují. Krásně zdokumentované posouzení bez postupu odstranění je stále otevřené zjištění.
Uzavřete to rozhodnutím, ne debatou
Ukončete výměnu písemným výsledkem: přijatá verze, kontroly k ní připojené, jmenovaní operátoři, důkazy, které stále chybí, a datum, kdy mají být dodány. Cokoli nevyřešeného se má zaznamenat jako podmínka, místo aby se vstřebalo do obecného prohlášení o schválení.
Pokud zásada jmenuje konkrétní schválený produkt, použijte cestu výjimky místo budování paralelního uspořádání, které nikdo neschválil. Přesvědčivý technický argument neuděluje povolení a neoficiální nasazení je zjištění čekající na odhalení.
Pokud požadavek skutečně nelze splnit, přejděte ke schválené alternativě a řekněte proč. Účelem cvičení je stanovit, na co se organizace může spolehnout, a jasné „ne“ je lepší výsledek než schválení, které později nikdo neobhájí.