Warum ein Open-Source-VPN in der Beschaffung abgelehnt wird
Wer gegen Open Source Einspruch erhebt, schützt meist eine Anforderung, nicht einen Lizenzgeschmack. Fragen Sie welche, und legen Sie dann das Artefakt vor, das sie beantwortet.
Ablehnungen, die Open Source anführen, drehen sich selten um die Lizenzierung. Der Prüfer schützt meist eine Anforderung: dass jemand das eingesetzte Release pflegt, dass sich der installierte Build identifizieren lässt, dass eine Bewertung abdeckt, was verbunden wird, oder dass die Verbindung zurückgezogen werden kann. Die folgende Debatte beantwortet meist eine Frage, die niemand gestellt hat.
Fragen Sie, welche Anforderung gilt, bevor Sie eine Lizenz verteidigen. Die Antwort entscheidet, welches Dokument Sie brauchen.
Das Etikett ist nicht die Anforderung
Lesbarer Quellcode bedeutet, dass die veröffentlichte Implementierung eingesehen werden kann. Es bedeutet nicht, dass jemand sie eingesehen hat, dass der Build am Gateway dem veröffentlichten entspricht oder dass ein Maintainer Ihrem Deployment eine Korrektur schuldet. Jede davon ist eine eigene Behauptung mit eigenem Eigentümer, und ein Prüfer, der eine davon braucht, wird durch die anderen nicht zufriedengestellt. Die Behauptung laut zu benennen reicht meist, um das Gespräch zu ändern.
Der umgekehrte Fehler ist ebenso verbreitet. Eine kommerzielle Lizenz beweist nicht, dass der Support die Funktion abdeckt, auf die Sie sich verlassen, dass eine Bewertung die von Ihnen eingesetzte Komponente untersucht hat oder dass der Anbieter eine Korrektur innerhalb Ihres Wartungsfensters liefert. Lizenzierung beschreibt Vertriebsbedingungen, während Beschaffungsentscheidungen Verlässlichkeit betreffen. So oder so ist die Lizenz der am wenigsten aussagekräftige Teil der Antwort.
Halten Sie auch Client und Dienst auseinander. Ein Audit eines Desktop-Clients sagt nichts über die Gateway-Konfiguration des Partners, seinen Identitätsanbieter oder die Art, wie seine Betreiber Kontolöschungen handhaben. Welche Belege Sie auch sammeln, sie müssen zur Grenze passen, der der Partner vertrauen soll.
Machen Sie das Bedenken zum Artefakt
Bitten Sie den Genehmiger, die Anforderung in einem Satz zu formulieren, und benennen Sie dann das Artefakt, das sie erfüllen würde. Gerade die vage Beruhigung macht diese Gespräche zu einer Debatte über 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 ist hier aus einem engen Grund nützlich: Es rahmt Beschaffungsgespräche um ein gemeinsames Vokabular von Praktiken und Lieferantenkommunikation. Das stützt die Forderung nach definierten Belegen statt einer Debatte über ein Etikett, und es ist keine Zertifizierung, die ein bestimmtes VPN besteht.
Beachten Sie, was die mittlere Spalte tut. Jede Zeile verlangt ein Dokument, das entweder existiert oder nicht, was eine Meinung in ein Ergebnis verwandelt, das jemand liefern oder ablehnen kann.
Trennen Sie den Client vom Dienst
Ein Supportvertrag für eine Client-Anwendung ist keine Zusage zum Server, den Ihr Datenverkehr erreicht. Bevor Sie Belege vorlegen, markieren Sie, welche Teile des Pfads der Partner betreibt und welche Sie in seinem Auftrag betreiben. Beides zu vermischen erzeugt ein Paket von Dokumenten, das gründlich aussieht und nichts beantwortet.
Ist das Deployment Ihres, muss der Partner möglicherweise nur einer Identität und einer Zugriffsregel vertrauen, was eine viel kleinere Bitte ist, als der gesamten Software-Lieferkette zu vertrauen. Ist das Deployment seines, kann der bevorzugte Client irrelevant sein und die Gateway-Konfiguration zum Thema werden. Zu klären, welcher Fall vorliegt, spart vor dem zweiten Termin einen Prüfzyklus.
Prüfen Sie dann die operativen Fragen, an denen Prüfungen tatsächlich scheitern: wer ein Konto entfernt, wie schnell und welche Belege danach vorliegen. Eine schön dokumentierte Bewertung ohne Löschverfahren ist weiterhin ein offener Befund.
Schließen Sie mit einer Entscheidung, nicht mit einer Debatte
Beenden Sie den Austausch mit einem schriftlichen Ergebnis: die akzeptierte Version, die daran gebundenen Kontrollen, die benannten Betreiber, die noch offenen Belege und das Datum, zu dem sie fällig sind. Alles Ungelöste sollte als Bedingung festgehalten werden, statt in eine allgemeine Genehmigungserklärung aufgenommen zu werden.
Wenn die Richtlinie ein bestimmtes genehmigtes Produkt nennt, nutzen Sie den Ausnahmeweg, statt eine parallele Regelung aufzubauen, die niemand genehmigt hat. Ein überzeugender technischer Fall erteilt keine Erlaubnis, und ein inoffizielles Deployment ist ein Befund, der darauf wartet, entdeckt zu werden.
Lässt sich eine Anforderung wirklich nicht erfüllen, wechseln Sie zur genehmigten Alternative und sagen Sie warum. Der Zweck der Übung ist festzustellen, worauf sich die Organisation verlassen kann, und ein klares Nein ist ein besseres Ergebnis als eine Genehmigung, die später niemand verteidigen kann.