Kvifor ein open kjeldekode-VPN blir avvist i anskaffingar
Ein gjennomgangar som motset seg open kjeldekode, vernar vanlegvis eit krav, ikkje ein lisenssmak. Spør kva, og legg deretter fram artefakten som svarer på det.
Avvisingar som viser til open kjeldekode, handlar sjeldan om lisensiering. Gjennomgangaren vernar vanlegvis eit krav: at nokon vedlikeheld utgåva som er teken i bruk, at den installerte byggjinga kan identifiserast, at ei vurdering dekkjer det som blir kopla til, eller at sambandet kan trekkjast tilbake. Debatten som følgjer, svarer vanlegvis på eit spørsmål ingen stilte.
Spør kva krav som gjeld, før du forsvarar ein lisens. Svaret avgjer kva dokument du treng.
Etiketten er ikkje kravet
Lesbar kjeldekode tyder at den publiserte implementeringa kan inspiserast. Det tyder ikkje at nokon har inspisert ho, at byggjinga på gatewayen svarar til den publiserte, eller at ein vedlikehaldar skuldar utrullinga di ei retting. Kvar av desse er ein eigen påstand med ein eigen eigar, og ein gjennomgangar som treng éin av dei, blir ikkje nøgd med dei andre. Å seie påstanden høgt er vanlegvis nok til å endre samtalen.
Den motsette feilen er like vanleg. Ein kommersiell lisens beviser ikkje at støtta dekkjer funksjonen du er avhengig av, at ei vurdering undersøkte komponenten du rullar ut, eller at leverandøren sender ei retting innanfor vedlikehaldsvindauget ditt. Lisensiering skildrar distribusjonsvilkår, medan anskaffingsavgjerder handlar om avhengnad. Uansett er lisensen den minst informative delen av svaret.
Hald òg klienten og tenesta frå kvarandre. Ein revisjon av ein skrivebordsklient seier ingenting om gateway-konfigurasjonen til partnaren, identitetsleverandøren deira eller måten operatørane deira handterer kontosletting. Kva bevis du enn samlar, må dei passe til grensa partnaren blir beden om å stole på.
Gjer uroa til ein artefakt
Be godkjenninga gi kravet form i éi setning, og nemn deretter artefakten som ville oppfylt det. Det er den vage beroliginga som gjer desse samtalene til ein debatt om ideologi.
| 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 er nyttig her av éin smal grunn: det rammar inn anskaffingssamtaler rundt eit felles ordforråd for praksis og leverandørkommunikasjon. Det støttar å be om definerte bevis i staden for å krangle om ein etikett, og det er ikkje ei sertifisering som ein bestemd VPN består.
Legg merke til kva den midtre kolonnen gjer. Kvar rad ber om eit dokument som anten finst eller ikkje, noko som gjer ei meining om til ei leveranse nokon kan produsere eller avvise.
Hald klienten og tenesta frå kvarandre
Ein støttekontrakt for ein klientapplikasjon er ikkje ei forplikting om serveren trafikken din når. Før du legg fram bevis, merk kva delar av banen partnaren driv og kva delar du driv på deira vegne. Å blande dei to gir ein pakke dokument som ser grundig ut og ikkje svarer på noko.
Om utrullinga er di, treng kanskje partnaren berre å stole på ein identitet og ei tilgangsregel, som er ei mykje mindre førespurnad enn å stole på heile programvareforsyningskjeda di. Om utrullinga er deira, kan klienten du føretrekkjer vere irrelevant, og gateway-konfigurasjonen blir temaet. Å finne ut kva tilfelle du er i før det andre møtet sparar ein gjennomgangssyklus.
Sjekk deretter dei operative spørsmåla gjennomgangane faktisk feilar på: kven som fjernar ein konto, kor raskt, og kva bevis som finst etterpå. Ei vakkert dokumentert vurdering utan ein sletteprosedyre er framleis eit ope funn.
Avslutt med ei avgjerd, ikkje ein debatt
Avslutt utvekslinga med eit skriftleg resultat: versjonen som er godteken, kontrollane knytte til han, dei namngjevne operatørane, bevisa som framleis manglar og datoen dei fell på. Alt uløyst bør registrerast som eit vilkår i staden for å bli absorbert i ei generell godkjenningsfråsegn.
Om policyen nemner eit bestemt godkjent produkt, bruk unntaksvegen i staden for å byggje ei parallell ordning ingen har autorisert. Eit overtydande teknisk argument gir ikkje løyve, og ei uoffisiell utrulling er eit funn som ventar på å bli oppdaga.
Om eit krav verkeleg ikkje kan oppfyllast, gå til det godkjende alternativet og seie kvifor. Føremålet med øvinga er å fastslå kva organisasjonen kan stole på, og eit klart nei er eit betre resultat enn ei godkjenning ingen seinare kan forsvare.