Hvorfor en åpen kildekode-VPN blir avvist i anskaffelser
En gjennomgåer som motsetter seg åpen kildekode, beskytter vanligvis et krav, ikke en lisenssmak. Spør hvilket, og legg deretter fram artefakten som svarer på det.
Avvisninger som viser til åpen kildekode, handler sjelden om lisensiering. Gjennomgåeren beskytter vanligvis et krav: at noen vedlikeholder utgivelsen som er tatt i bruk, at den installerte byggen kan identifiseres, at en vurdering dekker det som kobles til, eller at forbindelsen kan trekkes tilbake. Debatten som følger, svarer vanligvis på et spørsmål ingen stilte.
Spør hvilket krav som gjelder, før du forsvarer en lisens. Svaret avgjør hvilket dokument du trenger.
Etiketten er ikke kravet
Lesbar kildekode betyr at den publiserte implementeringen kan inspiseres. Det betyr ikke at noen har inspisert den, at byggen på gatewayen samsvarer med den publiserte, eller at en vedlikeholder skylder utrullingen din en rettelse. Hver av disse er en egen påstand med en egen eier, og en gjennomgåer som trenger én av dem, blir ikke tilfredsstilt av de andre. Å si påstanden høyt er vanligvis nok til å endre samtalen.
Den motsatte feilen er like vanlig. En kommersiell lisens beviser ikke at støtten dekker funksjonen du er avhengig av, at en vurdering undersøkte komponenten du ruller ut, eller at leverandøren sender en rettelse innenfor vedlikeholdsvinduet ditt. Lisensiering beskriver distribusjonsvilkår, mens anskaffelsesbeslutninger handler om avhengighet. Uansett er lisensen den minst informative delen av svaret.
Hold også klienten og tjenesten fra hverandre. En revisjon av en skrivebordsklient sier ingenting om partnerens gateway-konfigurasjon, identitetsleverandøren deres eller måten operatørene deres håndterer kontosletting. Uansett hvilke bevis du samler, må de passe til grensen partneren blir bedt om å stole på.
Gjør bekymringen til en artefakt
Be godkjenneren formulere kravet i én setning, og nevn deretter artefakten som ville oppfylt det. Det er den vage beroligelsen som gjør disse samtalene til en 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 én smal grunn: den rammer inn anskaffelsessamtaler rundt et felles ordforråd for praksis og leverandørkommunikasjon. Det støtter å be om definerte bevis i stedet for å krangle om en etikett, og det er ikke en sertifisering som en bestemt VPN består.
Legg merke til hva den midterste kolonnen gjør. Hver rad ber om et dokument som enten finnes eller ikke, noe som gjør en mening om til en leveranse noen kan produsere eller avvise.
Hold klienten og tjenesten fra hverandre
En støttekontrakt for en klientapplikasjon er ikke en forpliktelse om serveren trafikken din når. Før du legger fram bevis, marker hvilke deler av banen partneren driver og hvilke deler du driver på deres vegne. Å blande de to gir en pakke dokumenter som ser grundig ut og ikke svarer på noe.
Hvis utrullingen er din, trenger kanskje partneren bare å stole på en identitet og en tilgangsregel, som er en mye mindre forespørsel enn å stole på hele programvareforsyningskjeden din. Hvis utrullingen er deres, kan klienten du foretrekker være irrelevant, og gateway-konfigurasjonen blir temaet. Å finne ut hvilket tilfelle du er i før det andre møtet sparer en gjennomgåelsessyklus.
Sjekk deretter de operative spørsmålene gjennomgåelsene faktisk feiler på: hvem som fjerner en konto, hvor raskt, og hvilke bevis som finnes etterpå. En vakkert dokumentert vurdering uten en sletteprosedyre er fortsatt et åpent funn.
Avslutt med en beslutning, ikke en debatt
Avslutt utvekslingen med et skriftlig resultat: versjonen som er akseptert, kontrollene knyttet til den, de navngitte operatørene, bevisene som fortsatt mangler og datoen de forfaller. Alt uløst bør registreres som en betingelse i stedet for å bli absorbert i en generell godkjenningserklæring.
Hvis policyen navngir et bestemt godkjent produkt, bruk unntaksveien i stedet for å bygge en parallell ordning ingen har autorisert. Et overbevisende teknisk argument gir ikke tillatelse, og en uoffisiell utrulling er et funn som venter på å bli oppdaget.
Hvis et krav virkelig ikke kan oppfylles, gå til det godkjente alternativet og si hvorfor. Formålet med øvelsen er å fastslå hva organisasjonen kan stole på, og et klart nei er et bedre resultat enn en godkjenning ingen senere kan forsvare.