Varför en VPN med öppen källkod avvisas i upphandling
En granskare som invänder mot öppen källkod skyddar vanligtvis ett krav, inte en licenssmak. Fråga vilket, och ta sedan fram artefakten som svarar på det.
Avslag som hänvisar till öppen källkod handlar sällan om licensiering. Granskaren skyddar vanligtvis ett krav: att någon underhåller den driftsatta utgåvan, att den installerade byggen kan identifieras, att en bedömning täcker det som ansluts, eller att anslutningen kan dras tillbaka. Debatten som följer svarar vanligtvis på en fråga som ingen ställde.
Fråga vilket krav som gäller innan du försvarar en licens. Svaret avgör vilket dokument du behöver.
Etiketten är inte kravet
Läsbar källkod innebär att den publicerade implementationen kan granskas. Det innebär inte att någon har granskat den, att bygget på gatewayen matchar det publicerade, eller att en underhållare är skyldig din driftsättning en rättelse. Var och en av dessa är ett separat påstående med en separat ägare, och en granskare som behöver ett av dem blir inte nöjd med de andra. Att säga påståendet högt räcker oftast för att ändra samtalet.
Det omvända felet är lika vanligt. En kommersiell licens bevisar inte att stödet täcker den funktion du förlitar dig på, att en bedömning har undersökt den komponent du driftsätter, eller att leverantören skickar en rättelse inom ditt underhållsfönster. Licensiering beskriver distributionsvillkor, medan upphandlingsbeslut handlar om tillit. Hur som helst är licensen den minst informativa delen av svaret.
Håll också klienten och tjänsten åtskilda. En granskning av en skrivbordsklient säger ingenting om partnerns gatewaykonfiguration, dess identitetsleverantör eller hur dess operatörer hanterar kontoborttagning. Vilka bevis du än samlar in måste de passa den gräns som partnern ombeds lita på.
Gör oron till en artefakt
Be godkännaren formulera kravet i en mening och namnge sedan artefakten som skulle uppfylla det. Det är den vaga försäkran som gör dessa samtal till 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 är användbar här av en smal anledning: den ramar in upphandlingssamtal kring en gemensam vokabulär för praxis och leverantörskommunikation. Det stöder att be om definierade bevis i stället för att gräla om en etikett, och det är inte en certifiering som en viss VPN klarar.
Lägg märke till vad mittkolumnen gör. Varje rad ber om ett dokument som antingen finns eller inte, vilket förvandlar en åsikt till en leverans som någon kan producera eller avvisa.
Håll klienten och tjänsten åtskilda
Ett supportavtal för en klientapplikation är inte ett åtagande om servern som din trafik når. Innan du lägger fram bevis, markera vilka delar av vägen partnern driver och vilka delar du driver på deras vägnar. Att blanda de två ger ett paket dokument som ser grundligt ut och inte svarar på något.
Om driftsättningen är din behöver partnern kanske bara lita på en identitet och en åtkomstregel, vilket är en mycket mindre begäran än att lita på hela din programvaruleveranskedja. Om driftsättningen är deras kan klienten du föredrar vara irrelevant och gatewaykonfigurationen blir ämnet. Att ta reda på vilket fall du är i före det andra mötet sparar en granskningscykel.
Kontrollera sedan de operativa frågor som granskningar faktiskt misslyckas med: vem som tar bort ett konto, hur snabbt och vilka bevis som finns efteråt. En vackert dokumenterad bedömning utan borttagningsprocedur är fortfarande en öppen anmärkning.
Avsluta med ett beslut, inte en debatt
Avsluta utbytet med ett skriftligt resultat: den accepterade versionen, kontrollerna knutna till den, de namngivna operatörerna, bevisen som fortfarande saknas och datumet de ska levereras. Allt olöst bör registreras som ett villkor i stället för att absorberas i en allmän godkännandeförklaring.
Om policyn namnger en specifik godkänd produkt, använd undantagsvägen i stället för att bygga en parallell ordning som ingen har auktoriserat. Ett övertygande tekniskt argument ger inte tillstånd, och en inofficiell driftsättning är en anmärkning som väntar på att upptäckas.
Om ett krav verkligen inte kan uppfyllas, gå till det godkända alternativet och säg varför. Syftet med övningen är att fastställa vad organisationen kan lita på, och ett tydligt nej är ett bättre resultat än ett godkännande som ingen senare kan försvara.