Mit zunehmendem Einsatz von Open-Source-Software (OSS) wächst auch das Risiko. Dabei steht der Code an sich gar nicht mal im Vordergrund. Vielmehr geht es um die fehlenden Informationen darüber, was genau in den jeweiligen Code-Bausteinen steckt. Fünf Schritte helfen DevOps-Teams, Transparenz in die Software Supply Chain zu bringen und das Vertrauen in Open Source zu stärken.
Angesichts der wachsenden Komplexität von Software-Code führt kein Weg an Open Source Software-Komponenten vorbei. Nach einer Studie zur Software Supply Chain lassen sich ganze 61% der gescannten Codebase-Dateien mittlerweile OSS-Komponenten zuordnen. Das Problem: Die meisten Unternehmen sind sich nur eines kleinen Teils der von ihnen verwendeten Codebausteine auch bewusst.
Quelle: ReveneraInsgesamt werteten die Analysten mehr als 2,6 Milliarden Codezeilen aus und entdeckten dabei 230.000 kritische Fälle. Damit stieß das Audit-Team alle 11.500 Codezeilen auf einen Compliance-Verstoß, eine Sicherheitsschwachstelle oder ähnliches. 83% der in den Audits aufgedeckten Risiken war den Unternehmen im Vorfeld der Untersuchung nicht bekannt.
Ein häufiger Grund für die Betriebsblindheit in Sachen OSS ist das Fehlen von Software Composition Analyse (SCA)-Tools, die Anwendungen auf Codeebene scannen und Compliance-Verstöße sowie Sicherheitslücken automatisch melden.
Hinzu kommt, dass in vielen Unternehmen klare Prozesse fehlen, um in OSS-Komponenten entdeckte Sicherheitslücken nicht nur zu identifizieren, sondern auch ihre weitere Verbreitung zu stoppen. Ein proaktives Management von Open Source Software setzt dabei fünf wesentliche Best Practices voraus.
OSS-Ökosystem und SBOM für vorausschauende Planung
Proaktivität heißt vorausschauend zu planen. Grundvoraussetzung dafür ist ein ganzheitliches Ökosystem zur Verwaltung von Open Source – von den OSS-Komponenten über die zugehörigen Lizenzen und Compliance-Richtlinien bis hin zu bekannten Sicherheitslücken und Schwachstellen. Die Informationen sollten dabei nicht nur im Rahmen von DevOps geteilt und genutzt werden, sondern für verschiedenste Bereiche und Abteilungen im Unternehmen zugänglich sein. Automatisierte Scanning- und Monitoring-Tools helfen, einen Überblick über die im Produktportfolio verwendeten Komponenten zu schaffen und Risiken zu identifizieren, ehe sie sich in Bedrohungen verwandeln.
Software Composition Analysis gibt beispielsweise detailliert Aufschluss darüber, aus welchen Komponenten sich eine Software zusammensetzt, angefangen bei Paketen und Abhängigkeiten über Binärdateien ohne Manifest-Dateien, Multimedia-Dateien, Bilder/Icons, Codecs und Copy/Paste-Codes bis hin zu den von Entwicklern genutzten Source Libraries und Drittanbieter-Bibliotheken. Auf dieser Basis lässt sich die Software Bill-of-Material (SBOM) erstellen. Sie dient als seine Art Single-Source-of-Truth entlang der Software Supply Chain und wird bereits von vielen Unternehmen als Teil der SLA vertraglich vorausgesetzt.
Die SBOM ist nie ganz abgeschlossen, sondern muss mit jedem Release verfeinert und auf Lücken untersucht werden. Prozesse der Open Source Governance sollten daher über entsprechende Skalierbarkeit verfügen, um über die gesamte Lieferkette hinweg Informationen bereitzustellen. Das gilt sowohl für vorgelagerte Software- und Code-Lieferanten als auch für nachgelagerte Kunden und Partnern (Stichwort: Compliance-Artefakte).
Standards für fortlaufendes Scanning
Die kontinuierliche Überprüfung des Software-Code ist grundentscheidend für den Erfolg des OSS-Managements. Audits in letzter Minute vor dem Release sind weder ausreichend noch tatsächlich effizient. Stattdessen sollte das OS-Programm fest in der Toolchain integriert sein. Auf diese Weise werden Anwendungen an jedem Punkt des DevOps-Zyklus überprüft – angefangen beim Artefakt-Repository, innerhalb der integrierten Entwicklungsumgebung (IDE), während des Code-Check-Ins, als Teil der Build-Pipeline sowie bei der Bereitstellung der Software. Durch das kontinuierliche Scannen sind Unternehmen besser in der Lage, mit den immer schnelleren Release-Zyklen und der damit verbundenen wachsenden Menge an Drittanbietercode Schritt zu halten.
Das von der Linux Foundation ins Leben gerufene OpenChain-Projekt legt dafür den internationalen Standard (ISO/IEC 5230:2020) für die Einhaltung von OSS-Lizenzen vor. Zu den Kernelementen des Programms gehören definierte Rollen und Verantwortlichkeiten, Schulungen, eine dokumentierte OSS-Richtlinie, ein Prozess zur Identifizierung, Überprüfung und Behebung von OSS-Komponenten, die Erstellung von Compliance-Artefakten zur Einhaltung von Lizenzverpflichtungen und Branchenvorschriften sowie die aktive Einbindung in die Open Source Community.
Qualifizierte Teams: OSPO und OSRB
OSS-Management wird gerne als alleinige Aufgabe der Softwareentwickler angesehen. Der Trend zu DevSecOp hat viel zu dieser Einstellung beigetragen. Damit machen es sich Unternehmen allerdings zu einfach. Denn zum einen obliegt die Verantwortung für die OS-Governance nicht einem Team allein, sondern setzt die Mitarbeit von Rechtsexperten, Produktmanagern und Sicherheitsteams voraus. Zum anderen haben es viele Unternehmen bislang verpasst, spezifisches Open Source-Wissen aufzubauen und in entsprechende Aus- und Weiterbildungsprogramme zu investieren, die über die Pflichten, Einschränkungen und Risiken von OSS informieren.
Dezidierte OSS-Teams, sogenannte Open Source Program Office (OSPO) bestehen in der Regel aus Vertretern unterschiedlicher Bereiche (technisch und nicht-technisch) und folgen einer klar definierten Rollen- und Aufgabenverteilung. Gemeinsam lässt sich eine ganzheitliche Open Source-Strategie entwickeln und ein Framework zur Implementierung definieren. Open Source Review Boards (OSRBs) sind ein weiterer guter Ansatz, um verschiedene Experten an einen Tisch zu bringen und die Prozesse kontinuierlich zu verfeinern bzw. an neue Entwicklungen am Markt und in der Community anzupassen.
Vor- und Nachteile der Automatisierung
Ein hoher Automatisierungsgrad ermöglicht es Unternehmen, manuelle Aufgaben schneller auszuführen, Durchlaufzeiten zu verkürzen, die Fehlerquote zu verringern und damit Prozesse ganzheitlich zu optimieren. Automatisierung ist jedoch nicht immer das Maß aller Dinge. Die Komplexität von Software steigt und die Zahl an OSS- und Drittanbieter-Komponenten nimmt zu. Oft findet sich innerhalb von Anwendungen ein vielfältiger Mix an Technologien, von denen sich einige gut und andere weniger gut für die automatische Erkennung eignen. OSS-Management auf Knopfdruck kann in einigen Fällen funktionieren. In anderen sind weiterhin menschliches Know-how und Erfahrung gefragt.
Ein Blick auf das Kosten-Nutzen-Verhältnis hilft, den Einsatz von Zeit und Ressourcen nüchtern zu beurteilen. Wie viel Unternehmen hier bereit sind zu investieren, hängt von der jeweiligen Risikotoleranz ab. In jedem Fall sollten sich die Verantwortlichen ihrer Entscheidung bewusst sein und auf ein ausgewogenes Verhältnis zusteuern.
Lessons Learned: Einmal ein Risiko, immer ein Risiko
Proaktives Open-Source-Management setzt voraus, dass man aus den Erfahrungen der Vergangenheit lernt. Wird in der Open Source-Welt eine neue Sicherheitslücke bekannt gegeben, lohnt es sich also, den eigenen Software-Code nach der jeweiligen Schwachstelle zu untersuchen und wenn nötig die SBOM zu erweitern und die OSS-Governance anzuziehen.
Angreifbare Versionen von OpenSSL, die 2007 die Heartbleed-Sicherheitslücke verursachten, sind zum Beispiel heute noch in vielen Anwendungen zu finden. Und obwohl in den vergangenen Monaten fieberhaft an der Auffindung und der Log4Shell-Sicherheitslücke sowie deren Patches gearbeitet wurde, wird die Gefahr eines damit verbundenen Exploits Unternehmen weltweit noch eine ganz Weile begleiten. DevOps- wie OSS-Teams müssen sich der Langlebigkeit solcher Sicherheitsrisiken bewusst sein und ihre OSS-Governance dementsprechend darauf ausrichten.
Nicole Segerer ist Vice President of Product Management & Marketing bei Revenera.
