Heutige Software besteht zu großen Teilen aus fertigen Open-Source-Software-Komponenten (OSS). Dabei ist es wichtig zu wissen, was genau in meinem ausgelieferten Produkt steckt. Ohne dieses Wissen kann sich ein Unternehmen im schlimmsten Fall plötzlich in einer existenzgefährdenden Situation wiederfinden, z. B. falls eine Klage aufgrund einer Lizenzverletzung erhoben wird. Um dies zu verhindern, sollte die eingesetzte OSS „gemanagt“ werden, was unter dem Begriff „OSS Governance“ zusammengefasst wird.
Dieser Blog Post bietet eine kurze Einführung in das Thema und eine mögliche Herangehensweise für die Integration von OSS Governance in den eigenen Entwicklungsprozess.
Warum ist OSS Governance wichtig?
Die Nutzung von Open Source Komponenten hat die Softwareentwicklung stark beschleunigt. Entwickler:innen können diese Bausteine nutzen und sich auf ihre Geschäftslogik fokussieren, anstatt das Rad immer wieder neu zu erfinden. Die aktuellen Entwicklungsplattformen erlauben es den Entwickler:innen auf einfachste Weise die Verwendung und Einbindung solcher OSS-Komponenten. Leider wird dabei oft vernachlässigt, dass auch diese „Lieferkette“ geprüft und überwacht werden muss. Verschärft wird die Gefahr dadurch, dass die meisten OSS-Komponenten ihrerseits auf anderen Bausteinen aufbauen, wodurch diese Lieferkette immer größer wird.
Dabei kommen zwei Hauptaspekte zum Tragen: License Compliance (Einhaltung von Lizenzbestimmungen) und Vulnerability Analysis (Prüfung auf sicherheits- oder stabilitätsrelevante Schwachstellen).
Die Vernachlässigung von License Compliance kann im schlimmsten Fall existenzgefährdend für ein Unternehmen sein. So gibt es Open-Source-Lizenzen, welche unter bestimmten Umständen die Offenlegung des eigenen Quellcodes verlangen, wie z. B. Lizenzen aus der GNU-GPL-Familie. Wenn der Quellcode Geschäftsgeheimnisse beinhaltet, wie beispielsweise der Suchalgorithmus von Google, dann ist eine Veröffentlichung ein Desaster für das Unternehmen. In der Vergangenheit gab es immer wieder Gerichtsverfahren aufgrund von Verstößen gegen Open-Source-Lizenzbestimmungen, die oft durch finanzielle Kompensation beigelegt wurden.
Der Aussage „Sicherheit und Stabilität von Anwendungen ist wichtig“ können bestimmt alle Stakeholder eines Produktes zustimmen. Daher sollte es selbstverständlich sein, die verwendeten Open-Source-Komponenten dahingehend zu prüfen. Wer Software anbietet, die instabil ist oder sogar als Einfallstor für Angreifer genutzt wird, verliert schnell seinen jahrelang aufgebauten guten Ruf.
Unterm Strich ist OSS Governance für alle wichtig, die Open-Source-Komponenten verwenden. Aus der Erfahrung heraus ist allerdings für die meisten Unternehmen das Thema License Compliance der wichtigste Treiber bei der Einführung entsprechender Tools und Prozesse. Daher lege ich im Folgenden darauf den Fokus.
Wie starte ich am besten mit OSS Governance?
Vorweg sollte geklärt werden: Ab einer gewissen Projektgröße und -komplexität kann man realistisch nur das Risiko minimieren, gegen Lizenzbestimmungen zu verstoßen oder Schwachstellen zu übersehen. Das Risiko kann nur durch eine immens hohe Investition nahezu eliminiert werden. Daher gilt es, eine individuell angepasste und wirtschaftlich angemessene Vorgehensweise auszuarbeiten. Doch lassen Sie sich nicht davor zurückschrecken, denn dass Sie diesen Blog Post lesen und sich mit dem Thema beschäftigen, ist bereits der erste wichtige Schritt.
Auch ohne große Investitionen kann man leichtgewichtig in das Thema einsteigen, indem man z. B. eine erste Bestandsaufnahme für ein Projekt macht – um einschätzen zu können, welche Komponenten in einem Produkt stecken und welche Lizenzvereinbarungen an die Zulieferungen gekoppelt sind. In Anlehnung an die klassische analoge Fertigung bezeichnet man diesen Schritt ebenfalls als Erstellung einer „Bill of Materials“ (BoM, „Stückliste“). Mit diesen Informationen können die nächsten Schritte geplant werden, wie zum Beispiel die Überprüfung, ob ggf. schon Lizenzverstöße vorliegen. Im Kontext von Software spricht man deshalb auch von „Software Bill of Materials“, kurz SBoM. Für diese erste Bestandsaufnahme gibt es verschiedene Tools, auf die im nächsten Blog Post eingegangen wird.
Das BoM-Konzept ist eine etablierte Methode für traditionelle Herstellungsprozesse innerhalb des Supply-Chain-Managements. Abhängigkeiten können wie eine Lieferkette betrachten werden und SBoM ist einer der notwendigen Schritte diese Lieferkette zu dokumentieren. Damit es nicht bei einer einzelnen Bestandsaufnahme bleibt und das Thema sich wieder im Sande verläuft, sollte ein fester und verpflichtender Prozess etabliert werden.
Wie sieht ein möglicher Prozess aus?
Prinzipiell sollte ein Prozess sich grob an diesen Punkten orientieren:
- Man definiert, welche Lizenzen und Arten von Schwachstellen kritisch sind und welche Code-Teile geprüft werden.
- Auf Basis des Builds wird eine SBoM erzeugt.
- Die SBoM wird automatisch auf kritische Lizenzen und Schwachstellen geprüft.
- Die SBoM ist in irgendeiner Form mit dem Build verknüpft (“was habe ich wirklich ausgeliefert?”).
- Kritische Lizenzen oder Schwachstellen verhindern ein Release (“Gate”) oder schlagen zumindest anderweitig Alarm. Beide Varianten sollten durch einen automatisierten Prozess umgesetzt sein.
- Optional, falls möglich: Aus der SBoM wird automatisch ein „Notice File“ erzeugt, welches auch den Usern angezeigt wird.
Viele Lizenzen verlangen, dass der Lizenztext sowie ein „Copyright Notice“ der ausgelieferten Software beigelegt und den Nutzern zugänglich gemacht wird. Diese „Notices“ werden in der Regel pro eingebundenem Paket unter Angabe der Versionsnummer in einem „Notice File“ gesammelt und in der Applikation angezeigt.
Fazit und Ausblick
Einsatz von Open Source Software lohnt sich. Trotzdem ist es wichtig, die rechtlichen Vorgaben zu erfüllen und die Risiken für Schwachstellen entsprechend zu managen. Als erster Schritt ist eine Bestandsaufnahme mit diversen Tools relativ schnell machbar. Die Integration eines festen Prozesses in den Entwicklungsalltag sorgt dann dafür, dass nachhaltig sichere, stabile und lizenzkonforme Software ausgeliefert werden kann.
Diese Schritte passieren aber nicht nebenbei, sondern sollten erfahrungsgemäß als explizite Aufgaben eingeplant werden. Wir sind diesen Weg schon mehrfach gegangen und unterstützen Sie gerne dabei, OSS Governance auch bei Ihnen als Standard zu etablieren.
Im nächsten Blog Post werden einzelne Lösungsansätze mit kommerziellen und kostenlos verfügbaren Tools genauer betrachtet.
Sie wollen OSS Governance in Ihrem Unternehmen etablieren? Gerne unterstützen wir Sie bei der Einführung oder der technischen Umsetzung mit dem Ziel eine für Ihre Situation bestmögliche Lösung zu finden. Sprechen Sie uns an.