Open Source Software Governance – Hürden und Lösungen

Der letzte Blog Post bot eine kleine Einführung in das Thema und hat den Zielprozess umrissen. In diesem Blog Post gehe ich näher darauf ein, wie der Prozess mit kommerziellen und kostenlos verfügbaren Tools umzusetzen ist und auf welche Stolpersteine man achten sollte.

Welche Lösungsarten gibt es?

Die heutige Größe und Komplexität von Softwareprojekten macht es notwendig, dass die Analyse der genutzen Software-Komponenten durch Tools gestützt ist und nicht komplett manuell gestemmt wird. Auf der anderen Seite kann sie nicht rein automatisch stattfinden, sondern bedarf immer einer menschlichen Interaktion und Prüfung – oft durch die eigene Rechtsabteilung oder spezialisierte Anwaltskanzleien.

Für die Analyse gibt es grundsätzlich zwei Herangehensweisen: Basierend auf Paketmanager-Informationen oder direkt auf Quellcode bzw. kompilierten Binärdateien. Die meiste OSS ist als Abhängigkeit über einen Paketmanager (Bsp.: NuGet, npm) in Projekten eingebunden. Aus diesem Grund ist es häufig ausreichend, die bereits existierende Liste der Abhängigkeiten (z. B. package.json bei npm) zu nutzen. Wenn allerdings OSS direkt als Quellcode (Code Snippet oder ganze Datei) oder Binärdatei (z. B. direkte Referenz auf DLL) eingebunden wird, kann dies nur erkannt werden, wenn man diese Code- bzw. Binärdateien prüft.

Was kann ich von kostenlosen Lösungen erwarten?

Bei der Einführung von Tools zur Analyse der Abhängigkeiten zu OSS ist es – wie bei vielen heutigen Softwareprojekten – nicht sinnvoll, das Rad neu zu erfinden und eine komplett eigene Lösung aufzusetzen. Auch hier kann man wieder auf OSS oder kostenlose Services zurückgreifen. Dabei gibt es keine All-in-One-Lösung, denn oft muss man die passenden Tools je Programmiersprache heraussuchen und einzeln integrieren und anpassen. Der Eigenanteil beschränkt sich also maßgeblich auf die Integration bzw. Orchestrierung von frei verfügbaren Tools und Services.

Bei Nutzung von Open Source Tools hat man die volle Kontrolle und kann im Zweifelsfall auch selbst Fehler beheben oder neue Features entwickeln.

Kostenlose Services erleichtern vor allem den Einstieg, aber dabei muss man sich immer dem Risiko bewusst sein, dass sie jederzeit eingestellt oder eingeschränkt werden können. So wurde beispielsweiseder kostenlose Service „Whitesource Bolt“ für Azure DevOps Server (on-premise) eingestellt und wird aktuell nur noch für Azure DevOps Services (Cloud) unterstützt.

Whitesource Bolt

Als kostenloser Service kann Whitesource Bolt genutzt werden. Dieser ist allerdings nur für GitHub oder Azure DevOps Services verfügbar, also nicht on-premise. Die Einrichtung ist sehr leicht. Es werden 14 Programmiersprachen unterstützt, darunter C# und JavaScript. Eine Gegenüberstellung der kostenlosen Variante Bolt und der vollen Lösung ist online zu finden.

Whitesource nutzt alle Informationsquellen, in erster Linie aber erstellt es eine digitale Signatur (vermutlich ähnlich wie ein Hash, die Details hält Whitesource natürlich geheim) des Quellcodes bzw. der Binärdateien (je nach Technologie) und gleicht diese in der Cloud mit ihrer eigenen Datenbank ab. Dadurch werden auch Code Snippets oder direkt referenzierte DLLs erkannt.

Es sind nur wenige Scans pro Tag verfügbar und es wird pro Projekt nur der letzte Scan gespeichert. Über ein Dashboard können die Ergebnisse der Analyse eingesehen werden. Geprüft werden Lizenzen und Schwachstellen. Allerdings bietet das Dashboard nur eingeschränkte Möglichkeiten zur Analyse. So werden z. B. nur die OSS-Pakete mit Namen, Versionsnummer und Lizenzname aufgelistet, aber nicht an welcher Stelle im Code oder in welcher Projektdatei sie eingebunden sind. Eine Automatisierung über eine API ist nicht möglich. Man kann zwar die Ergebnisse manuell herunterladen (u. a. im JSON-Format), sie persistieren und weiter automatisiert auswerten, jedoch muss dazu viel selbst gebaut werden. Außerdem wird kein Notice-File erstellt. Die vielen manuellen Schritte stellen eine große Hürde für Projekte mit kurzen Release-Zyklen dar.

Für eine erste Bestandsaufnahme eignet es sich jedoch sehr gut. Für kleine bis mittelgroße Projekte mit längeren Release-Zyklen kann es sogar viele Teile des gewünschten OSS-Governance-Prozesses abdecken.

Open-Source-Tools

Im Vergleich zu Whitesource Bolt sind die verfügbaren Open-Source-Tools mächtiger, jedoch schwieriger einzurichten. Außerdem gibt es keine vergleichbare All-in-One-Lösung, sondern man muss mehrere Tools einsetzen. Man sollte Zeit einplanen, um Bugs zu fixen oder Features zu implementieren, und man sollte auch bereit sein, diese Änderungen wieder der Community bereitzustellen.

Die hier vorgestellten Open-Source-Tools nutzen zur Analyse nur die Paketmanager-Informationen, d.h. die OSS muss sauber als Paket eingebunden sein, um auch erfasst werden zu können. Da die meisten Open-Source-Tools keine Benutzeroberfläche haben, sind sie eher für Entwickler mit Affinität zur Kommandozeile geeignet. Die Wahl der Tools hängt auch davon ab, auf welcher Plattform das Projekt und der CI/CD-Prozess gehostet wird.

OSS Governance auf GitHub

Bei Projekten auf GitHub (unter Nutzung von GitHub Actions) eignet sich GitHub Licensed für die Lizenzprüfung und Dependabot für die Vulnerability Analysis. Beide Tools decken diverse Programmiersprachen ab und werden direkt von GitHub gepflegt.

Dependabot ist inzwischen als native Funktionalität in GitHub integriert und erstellt ganz automatisch Pull Requests mit allen notwendigen Änderungen für Pakete, welche auf eine neuere Version aktualisiert werden sollen.

GitHub Licensed kann als Action in einen Workflow integriert oder auch lokal von den Entwicklern installiert und genutzt werden. Damit lässt sich sogar automatisiert ein Notice-File erstellen. Falls eine unerwünschte oder fehlende Lizenz entdeckt wurde, kann der GitHub Workflow abgebrochen werden. Je nach Konfiguration kann genau das Projekt ausgelesen werden, in welchem ein Paket mit einer unerwünschten Lizenz gefunden wurde. Die Ergebnisse werden aber z.T. nicht immer übersichtlich angezeigt, daher bietet es sich an, die Ergebnisse mit kleinen Hilfsskripten zu analysieren und aufzubereiten oder – das ist die beste Variante – eine übersichtliche Anzeige nativ in die Tools zu integrieren und dies in deren öffentliches Repository einzuspielen, um von Ideen und Weiterentwicklung durch die Community zu profitieren.

OSS Governance in Azure DevOps

Dependabot ist offiziell aktuell leider nur für GitHub verfügbar. Für Azure DevOps existiert nur eine inoffizielle Extension. Prinzipiell kann diese aber genutzt bzw. eigene Lösungen basierend darauf entwickelt werden, denn alles ist frei verfügbar als OSS (Achtung: Dependabot kann in der Entwicklung von kommerziellen Produkten frei verwendet werden, darf aber nicht selbst in einem kommerziellen Produkt verkauft werden. Details in der Lizenz).

Vulnerability Analysis kann aber auch mit anderen Tools für einzelne Programmiersprachen und ihre Paketmanager eingerichtet werden. So gibt es für npm ab Version 6 den Befehl „npm audit“, um veraltete Pakete mit Schwachstellen zu identifizieren und sogar automatisch auf die neuere Version zu aktualisieren. Für NuGet in Projekten ab .NET 5 gibt es ebenfalls einen dotnet CLI Befehl, um auf Pakete mit Schwachstellen zu prüfen.

Zur Einhaltung der License Compliance kann auch in Azure DevOps GitHub Licensed eingesetzt werden, da es überall lokal installiert und über die Kommandozeile genutzt werden kann. Da es im Marketplace bisher keine Extension gibt, muss die Integration in die CI/CD-Pipeline manuell erfolgen, z. B. den Exit Code auslesen und Build-/Release-Prozess ggf. abbrechen oder eine Warnung loggen lassen.

Fazit für kostenlose Lösungen

Die initiale Einrichtung kann eine Hürde für Neulinge darstellen. Oft werden nur die neuesten Versionen unterstützt, so ist z.B. GitHub Licensed nur kompatibel mit NuGet-Paketen, welche als PackageReference und nicht über die alte package.json-Datei eingebunden sind. Bestandsprojekte müssen daher erst migriert werden – je nach Projekt kann dies sogar ein Ausschlusskriterium sein.

Jedoch kann mit einer Kombination aus frei verfügbaren Tools der komplette gewünschte OSS-Governance-Prozess aufgesetzt werden. Der Aufwand hierfür hängt stark davon ab, was alles automatisiert und abgesichert oder wie komfortabel der Prozess gestaltet sein soll.

Sollte ich besser eine bezahlte Lösung verwenden?

Diese Frage stellt sich unmittelbar, wenn man die Hürden von kostenlosen Lösungen betrachtet. Tatsächlich bieten bezahlte Lösungen im Vergleich immense Vorteile. Sie sind meist zuverlässiger und aktueller (gerade bei Vulnerability Analysis), einfacher einzurichten, decken viele Programmiersprachen ab und bieten ein SLA. Jedoch schrecken viele unserer Kunden vor den hohen Preisen zurück.

Zu den bekanntesten Anbietern gehören Black Duck, Snyk und Whitesource. Beispielhaft möchte ich hier Whitesource näher betrachten.

Wie schon oben bei der kostenlosen Variante Whitesource Bolt beschrieben, nutzt Whitesource alle zur Verfügung stehenden Informationsquellen. Zur Erstellung der SBoM („Software Bill of Materials“) wird eine digitale Signatur erstellt und online mit einer bestehenden Datenbank abgeglichen. Es wird also kein Quellcode an die Whitesource-Server übermittelt. Für die weitere Verarbeitung der Lizenzen werden aber auch Informationen aus den Paketmanager-Dateien und anderen zuverlässigen Online-Quellen herangezogen.

Für Lizenzen und Schwachstellen lässt sich genau konfigurieren, was erlaubt ist (Allowlist, Blocklist) und was eine Warnung oder einen Fehler ausgeben soll. Dabei sind Benachrichtigungen einzelner Personen sowie eine Integration als Gate in einer CI/CD-Pipeline möglich. Native Integration gibt es primär für die Cloud-Plattformen wie GitHub und Azure DevOps Services. Für den on-premise-hosted Azure DevOps Server oder andere Systeme gibt es ein Java-Kommandozeilen-Tool („Unified Agent“), welches ebenfalls mächtig ist, aber mehr manuelle Konfiguration benötigt.

Die Verwaltung erfolgt in der eigenen Weboberfläche, in welcher auch zu jeder Pipeline alle Informationen zur SBoM, Lizenzen und Schwachstellen aufgelistet sind. Dabei kann genau zurückverfolgt werden, in welcher Datei ein Risiko oder eine Lizenz gefunden wurde. Es können diverse Reports über die Oberfläche oder auch einer HTTP-API exportiert werden, darunter auch ein anpassbarer „Attribution Report“ (entspricht dem Notice-File).

Mit Whitesource kann man den gesamten gewünschten OSS-Governance-Prozess abbilden und hochgradig automatisieren. Zudem bietet es eine Benutzeroberfläche und vorgefertigte Dashboards und Reports an. Diese Funktionalitäten haben allerdings ihren stolzen Preis.

Die obige Beschreibung gilt für die „Teams“- und „Enterprise“-Varianten. Die Teams-Variante gibt es für mindestens 20 Entwickler für 10.000 USD pro Jahr, jede 5 weitere Entwickler kosten zusätzlich 2.500 USD.

Als Einstieg wird noch eine „Essentials“-Variante angeboten, welche bereits ab einem Entwickler für 120 USD pro Kopf und Jahr zu haben ist. Allerdings ist der Funktionsumfang hier stark eingeschränkt, so gibt es z.B. keinen API-Zugriff oder die Lizenzinformationen werden nur aggregiert pro Pipeline angezeigt, sodass nicht klar ist, in welcher Komponente / Datei ggf. eine Abhängigkeit zu einer unerwünschten Lizenz besteht. Der große Vorteil der Automatisierung geht also verloren. In der Praxis fühlt es sich eher wie eine bessere Variante des kostenlosen Whitesource Bolt an, ist aber Lichtjahre von einem Whitesource Teams entfernt. Daher eignet es sich am ehesten für Projektteams, die bereits gute Erfahrungen mit Whitesource Bolt gesammelt haben und den nächsten Schritt zu einer besseren OSS Governance machen wollen. Der Mehrwert von Essentials liegt primär darin, dass beliebig viele Scans durchgeführt werden können und ein zentrales Portal mit Informationen für alle Pipelines bereitgestellt wird.

Das zentrale Portal von Whitesource darf auch als eine der Kernfunktionen für alle Stakeholder im Projekt, welche nicht Entwickler sind, betrachtet werden. Pipelineübergreifend alle relevanten Informationen zu den verwendeten Lizenzen an einem Ort zu haben ist einer der Hauptvorteile von kommerziellen gegenüber kostenlosen Lösungen.

Fazit

OSS Governance ist leider ein mehrheitlich vernachlässigter Aspekt der modernen Softwareentwicklung. Trotz fertiger und sogar kostenloser Tools wie Whitesource (Bolt oder Teams als Trial-Version) gibt es eine Einstiegshürde, die aber mit überschaubarem Aufwand überwunden werden kann. Nach einer ersten Bestandsaufnahme können die weiteren Schritte beschlossen werden, je nach individuellem Risiko und einer Kosten-Nutzen-Betrachtung.

Für Projekte mit Source Control und CI/CD-Pipeline in der Cloud bietet sich Whitesource Bolt als leichtgewichtige Variante auch für einen rudimentären OSS-Governance-Prozess an. Für wenig Geld bekommt man mit Whitesource Essentials etwas mehr Funktionalität und Komfort.

Für Projekte, die mehr Automatisierung im Prozess benötigen oder on-premise-hosted sind, sollte man hingegen eher zu Open-Source-Tools greifen, wenn man die hohen Fixkosten von kommerziellen Komplettlösungen scheut. Doch Vorsicht: Der Aufwand für Anpassung, Integration und Betrieb von Open-Source-Tools sollte nicht unterschätzt werden.

Für Projekte, in denen OSS exzessiv genutzt wird oder welche viele und/oder kurzfristige Releases mit viel Automatisierung benötigen, sollte man genau abwägen, ob man das Geld besser in eine fertige kommerzielle Lösung investieren sollte.

Egal wie man sich entscheidet, wichtig ist es, dass das Thema bewusst angegangen wird und gemäß den individuellen Rahmenbedingungen ein nachhaltiger OSS-Governance-Prozess implementiert wird.

Den für Sie richtigen Weg können wir gerne gemeinsam finden. Sprechen sie uns an!

Titelbild: Darwin Laganzon on Pixabay