Hvorfor en open source-VPN bliver afvist i indkøb
En bedømmer, der protesterer mod open source, beskytter normalt et krav, ikke en licenssmag. Spørg hvilket, og fremlæg så det artefakt, der besvarer det.
Afvisninger, der henviser til open source, handler sjældent om licensering. Bedømmeren beskytter normalt et krav: at nogen vedligeholder den udbredte version, at den installerede build kan identificeres, at en vurdering dækker det, der forbindes, eller at forbindelsen kan trækkes tilbage. Den debat, der følger, besvarer normalt et spørgsmål, som ingen stillede.
Spørg hvilket krav der gælder, før du forsvarer en licens. Svaret afgør, hvilket dokument du har brug for.
Etiketten er ikke kravet
Læsbar kildekode betyder, at den offentliggjorte implementering kan inspiceres. Det betyder ikke, at nogen har inspiceret den, at builden på gatewayen svarer til den offentliggjorte, eller at en vedligeholder skylder din udrulning en rettelse. Hver af disse er en separat påstand med en separat ejer, og en bedømmer, der har brug for én af dem, bliver ikke tilfredsstillet af de andre. At sige påstanden højt er normalt nok til at ændre samtalen.
Den omvendte fejl er lige så almindelig. En kommerciel licens beviser ikke, at support dækker den funktion, du er afhængig af, at en vurdering undersøgte den komponent, du udruller, eller at leverandøren sender en rettelse inden for dit vedligeholdelsesvindue. Licensering beskriver distributionsvilkår, mens indkøbsbeslutninger handler om afhængighed. I begge tilfælde er licensen den mindst informative del af svaret.
Hold også klienten og tjenesten adskilt. En revision af en skrivebordsklient siger intet om partnerens gateway-konfiguration, dens identitetsudbyder eller måden, hvorpå dens operatører håndterer kontosletning. Uanset hvilke beviser du indsamler, skal de passe til den grænse, partneren bliver bedt om at stole på.
Gør bekymringen til et artefakt
Bed godkenderen om at formulere kravet i én sætning, og navngiv derefter det artefakt, der ville opfylde det. Det er den vage beroligelse, der gør disse samtaler til en debat 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 af én snæver grund: den rammer indkøbssamtaler ind i et fælles ordforråd for praksis og leverandørkommunikation. Det understøtter at bede om definerede beviser i stedet for at diskutere en etiket, og det er ikke en certificering, som en bestemt VPN består.
Læg mærke til, hvad den midterste kolonne gør. Hver række beder om et dokument, der enten findes eller ikke findes, hvilket omdanner en mening til en leverance, som nogen kan producere eller afvise.
Adskil klienten fra tjenesten
En supportkontrakt for en klientapplikation er ikke en forpligtelse vedrørende den server, din trafik når. Før du fremlægger beviser, skal du markere, hvilke dele af ruten partneren driver, og hvilke dele du driver på deres vegne. At blande de to skaber en pakke dokumenter, der ser grundig ud og ikke besvarer noget.
Hvis udrulningen er din, behøver partneren måske kun at stole på en identitet og en adgangsregel, hvilket er en meget mindre anmodning end at stole på hele din softwareleverandørkæde. Hvis udrulningen er deres, kan den klient, du foretrækker, være irrelevant, og gateway-konfigurationen bliver emnet. At finde ud af, hvilket tilfælde du er i, inden det andet møde sparer en gennemgangscyklus.
Kontroller derefter de operationelle spørgsmål, som gennemgange faktisk fejler på: hvem fjerner en konto, hvor hurtigt, og hvilke beviser findes bagefter. En smukt dokumenteret vurdering uden en sletningsprocedure er stadig en åben konstatering.
Afslut med en beslutning, ikke en debat
Afslut udvekslingen med et skriftligt resultat: den accepterede version, de kontroller, der er knyttet til den, de navngivne operatører, de beviser, der stadig mangler, og den dato, de skal foreligge. Alt uafklaret bør registreres som en betingelse i stedet for at blive absorberet i en generel godkendelseserklæring.
Hvis politikken navngiver et bestemt godkendt produkt, brug undtagelsesvejen i stedet for at bygge en parallel ordning, som ingen har godkendt. En overbevisende teknisk sag giver ikke tilladelse, og en uofficiel udrulning er en konstatering, der venter på at blive opdaget.
Hvis et krav virkelig ikke kan opfyldes, gå til det godkendte alternativ og sig hvorfor. Formålet med øvelsen er at fastslå, hvad organisationen kan stole på, og et klart nej er et bedre resultat end en godkendelse, som ingen senere kan forsvare.