Miért utasítják el a nyílt forráskódú VPN-t a beszerzésben
Aki a nyílt forráskód ellen tiltakozik, általában egy követelményt véd, nem licencízlés kérdése. Kérdezze meg, melyiket, majd állítsa elő azt az artefaktumot, amely megválaszolja.
A nyílt forráskódra hivatkozó elutasítások ritkán a licencelésről szólnak. A bíráló általában egy követelményt véd: hogy valaki karbantartja a bevezetett kiadást, hogy az telepített build azonosítható legyen, hogy egy értékelés lefedje, ami csatlakozik, vagy hogy a kapcsolat visszavonható legyen. Az ezt követő vita általában olyan kérdésre válaszol, amelyet senki nem tett fel.
Kérdezze meg, melyik követelmény érvényes, mielőtt egy licencet megvéd. A válasz dönti el, melyik dokumentumra van szüksége.
A címke nem a követelmény
Az olvasható forráskód azt jelenti, hogy a közzétett megvalósítás megvizsgálható. Nem azt jelenti, hogy valaki megvizsgálta, hogy az átjárón lévő build megegyezik a közzétettel, vagy hogy egy karbantartó javítással tartozik az ön telepítésének. Ezek mindegyike külön állítás külön tulajdonossal, és az a bíráló, akinek egyre szüksége van, nem elégszik meg a többivel. Az állítás hangos kimondása általában elég a beszélgetés megváltoztatásához.
A fordított hiba ugyanolyan gyakori. A kereskedelmi licenc nem bizonyítja, hogy a támogatás lefedi a funkciót, amelyre támaszkodik, hogy egy értékelés megvizsgálta az ön által telepített komponenst, vagy hogy a szállító javítást küld a karbantartási ablakán belül. A licencelés a terjesztési feltételeket írja le, míg a beszerzési döntések a megbízhatóságról szólnak. Mindkét esetben a licenc a válasz legkevésbé informatív része.
Tartsa külön az ügyfelet és a szolgáltatást is. Egy asztali kliens auditja semmit nem mond a partner átjáró-konfigurációjáról, identitásszolgáltatójáról vagy arról, hogyan kezelik az operátorai a fiókok eltávolítását. Bármilyen bizonyítékot is gyűjt, annak meg kell felelnie annak a határnak, amelyet a partnernek meg kell bíznia.
Tegye az aggodalmat dokumentummá
Kérje meg a jóváhagyót, hogy egy mondatban fogalmazza meg a követelményt, majd nevezze meg az artefaktumot, amely kielégítené. A homályos megnyugtatás az, ami ezeket a beszélgetéseket ideológiáról szóló vitává teszi.
| 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 itt egy szűk okból hasznos: a beszerzési beszélgetéseket a gyakorlatok és a szállítói kommunikáció közös szókincse köré rendezi. Ez a meghatározott bizonyítékok kérését támogatja a címkéről való vita helyett, és nem olyan tanúsítás, amelyet bármely konkrét VPN teljesít.
Figyelje meg, mit tesz a középső oszlop. Minden sor olyan dokumentumot kér, amely vagy létezik, vagy nem, ami a véleményt olyan szállítmánnyá alakítja, amelyet valaki előállíthat vagy megtagadhat.
Válassza külön az ügyfelet a szolgáltatástól
Egy kliensalkalmazás támogatási szerződése nem kötelezettségvállalás arról a szerverről, amelyet a forgalma elér. Mielőtt bizonyítékot mutat be, jelölje meg, az útvonal mely részeit üzemelteti a partner, és melyeket ön az ő nevében. A kettő keverése olyan dokumentumcsomagot hoz létre, amely alaposnak tűnik, és semmire nem válaszol.
Ha a telepítés az öné, lehet, hogy a partnernek csak egy identitásban és egy hozzáférési szabályban kell megbíznia, ami sokkal kisebb kérés, mint a teljes szoftver-ellátási láncában megbízni. Ha a telepítés az övé, az ön által preferált kliens irreleváns lehet, és az átjáró-konfiguráció válik a témává. Ha a második megbeszélés előtt tisztázza, melyik esetben van, egy felülvizsgálati ciklust takarít meg.
Ezután ellenőrizze azokat a működési kérdéseket, amelyeken a felülvizsgálatok valóban elbuknak: ki távolít el egy fiókot, milyen gyorsan, és milyen bizonyíték marad utána. A szépen dokumentált értékelés eltávolítási eljárás nélkül továbbra is nyitott megállapítás.
Döntéssel zárja le, ne vitával
Fejezze be az eszmecserét írásos eredménnyel: az elfogadott verzió, a hozzá kapcsolt kontrollok, a megnevezett operátorok, a még hiányzó bizonyítékok és az a határidő, ameddig azokat be kell nyújtani. Minden megoldatlant feltételként kell rögzíteni, ahelyett hogy egy általános jóváhagyási nyilatkozatba olvasztanák.
Ha a szabályzat konkrét jóváhagyott terméket nevez meg, használja a kivételi utat, ahelyett hogy olyan párhuzamos megoldást építene, amelyet senki nem hatalmazott fel. A meggyőző műszaki érvelés nem ad engedélyt, és a nem hivatalos telepítés olyan megállapítás, amely arra vár, hogy felfedezzék.
Ha egy követelmény valóban nem teljesíthető, térjen át a jóváhagyott alternatívára, és mondja meg, miért. A gyakorlat célja annak megállapítása, mire támaszkodhat a szervezet, és a világos nem jobb eredmény, mint egy olyan jóváhagyás, amelyet később senki nem tud megvédeni.