Waarom een opensource-VPN bij inkoop wordt afgewezen
Een beoordelaar die bezwaar maakt tegen open source beschermt meestal een eis, niet een licentiesmaak. Vraag welke, en lever dan het artefact dat er antwoord op geeft.
Afwijzingen die open source noemen, gaan zelden over licentiëring. De beoordelaar beschermt meestal een eis: dat iemand de uitgerolde release onderhoudt, dat de geïnstalleerde build kan worden geïdentificeerd, dat een beoordeling dekt wat er wordt verbonden, of dat de verbinding kan worden ingetrokken. Het debat dat volgt beantwoordt meestal een vraag die niemand stelde.
Vraag welke eis van toepassing is voordat je een licentie verdedigt. Het antwoord bepaalt welk document je nodig hebt.
Het label is niet de eis
Leesbare broncode betekent dat de gepubliceerde implementatie kan worden geïnspecteerd. Het betekent niet dat iemand die heeft geïnspecteerd, dat de build op de gateway overeenkomt met de gepubliceerde, of dat een maintainer jouw uitrol een correctie schuldig is. Elk daarvan is een afzonderlijke claim met een afzonderlijke eigenaar, en een beoordelaar die er één nodig heeft, wordt niet tevreden gesteld door de andere. De claim hardop benoemen is meestal genoeg om het gesprek te veranderen.
De omgekeerde fout is even gewoon. Een commerciële licentie bewijst niet dat ondersteuning de functie dekt waarop je vertrouwt, dat een beoordeling de component heeft onderzocht die je uitrolt, of dat de leverancier een correctie levert binnen je onderhoudsvenster. Licentiëring beschrijft distributievoorwaarden, terwijl inkoopbeslissingen over vertrouwen gaan. Hoe dan ook is de licentie het minst informatieve deel van het antwoord.
Houd ook de client en de dienst apart. Een audit van een desktopclient zegt niets over de gatewayconfiguratie van de partner, diens identiteitsprovider of de manier waarop de operators accounts verwijderen. Welk bewijs je ook verzamelt, het moet passen bij de grens die de partner wordt gevraagd te vertrouwen.
Maak van de zorg een artefact
Vraag de goedkeurder de eis in één zin te formuleren en noem vervolgens het artefact dat eraan zou voldoen. Juist de vage geruststelling maakt van deze gesprekken een debat over ideologie.
| 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 is hier nuttig om één smalle reden: het kadert inkoopgesprekken rond een gedeelde woordenschat van praktijken en leverancierscommunicatie. Dat ondersteunt het vragen om gedefinieerd bewijs in plaats van een discussie over een label, en het is geen certificering die een bepaalde VPN haalt.
Let op wat de middelste kolom doet. Elke rij vraagt om een document dat bestaat of niet, wat een mening omzet in een oplevering die iemand kan produceren of weigeren.
Houd de client en de dienst apart
Een ondersteuningscontract voor een clientapplicatie is geen toezegging over de server die je verkeer bereikt. Voordat je bewijs presenteert, markeer welke delen van het pad de partner beheert en welke delen jij namens hem beheert. Het mengen van beide levert een pakket documenten op dat grondig lijkt en niets beantwoordt.
Als de uitrol de jouwe is, hoeft de partner misschien alleen een identiteit en een toegangsregel te vertrouwen, wat een veel kleinere vraag is dan je hele softwaretoeleveringsketen vertrouwen. Als de uitrol de zijne is, kan de client die je verkiest irrelevant zijn en wordt de gatewayconfiguratie het onderwerp. Vaststellen in welk geval je zit vóór de tweede bijeenkomst bespaart een beoordelingscyclus.
Controleer daarna de operationele vragen waarop beoordelingen echt falen: wie verwijdert een account, hoe snel, en welk bewijs bestaat er daarna. Een prachtig gedocumenteerde beoordeling zonder verwijderingsprocedure blijft een open bevinding.
Sluit af met een besluit, niet met een debat
Sluit de uitwisseling af met een schriftelijk resultaat: de geaccepteerde versie, de bijbehorende controles, de genoemde operators, het bewijs dat nog ontbreekt en de datum waarop het moet worden geleverd. Alles wat onopgelost is, moet als voorwaarde worden vastgelegd in plaats van te worden opgenomen in een algemene goedkeuringsverklaring.
Als het beleid een specifiek goedgekeurd product noemt, gebruik dan de uitzonderingsroute in plaats van een parallelle regeling te bouwen die niemand heeft geautoriseerd. Een overtuigend technisch argument verleent geen toestemming, en een niet-officiële uitrol is een bevinding die wacht om ontdekt te worden.
Als een eis echt niet kan worden vervuld, ga dan naar het goedgekeurde alternatief en zeg waarom. Het doel van de oefening is vaststellen waarop de organisatie kan vertrouwen, en een duidelijk nee is een beter resultaat dan een goedkeuring die niemand later kan verdedigen.