Supply Chain

Open Source Software: Verstecktes Sicherheits-Risiko im Code

26.07.2022, Hamburg, Revenera | Autor: Nicole Segerer

Nicole Segerer, VP of Product Management & Marketing, Revenera

SaaS, Cloud, KI – wer auf die Digitalisierung setzt, muss sich auf eine sichere und lückenlose digitale Supply Chain verlassen können. Gerade im Zusammenhang mit Open Source Software (OSS) folgten hier viele Unternehmen der Vogel-Strauß-Taktik. Gefragt sind jedoch neue Lösungen und Standards – von Software Composition Analysis (SCA) bis hin zur Software-BOM.

Fast zwei Drittel (64%) der Unternehmen hatten 2021 mit Angriffen auf die Software Supply Chain zu kämpfen. Überhaupt hatte es das letzte Jahr in Sachen Cyber Security in sich: Erst kam der Mega-Hack rund um SolarWinds und Microsoft Exchange. Dann hielt die kritische Zero-Day-Schwachstelle in Log4j Sicherheitsteams in Atem. Und schließlich zeigte der Hackerangriff auf die US-Pipeline Colonia eindrücklich, wie verletzlich kritische Infrastrukturen (KRITIS) tatsächlich sind. Eine Gefahr, die seit dem Angriffskriegs Russlands auf die Ukraine übrigens weiter zugenommen hat.

Risikofaktor Open Source Software

Ein Ende der Cyberbedrohungen ist ebenso unwahrscheinlich wie das Ende der Digitalisierung. In dem Maße wie die digitale Transformation voranschreitet, wächst auch der Einsatz von Software und damit die Nutzung von Open Source Software (OSS)-Komponenten sowie Drittanbieter-Code. Dass Softwarehersteller und Entwickler dabei unbeabsichtigt Fehler und Hintertüren für Exploits in die eigenen Anwendungen einprogrammieren, ist nicht nur wahrscheinlich, sondern sicher. Und was einmal in der Software steckt, wird entlang der Supply Chain auch an Partner und Kunden weitergegeben.

Theoretisch wäre das kein Problem. Software wird regelmäßig getestet und Schwachstellen upgedatet. OSS-Komponenten unterliegen zudem ohnehin dem „Mehr-Augen-Prinzip“ und werden permanent von Seiten der Entwickler-Community überprüft und verbessert. Reicht das nicht aus? Leider nicht. Entwickler- und Sicherheitsteams fehlt es gleichermaßen an Zeit, Geld und Ressourcen, um der wachsenden Menge an Softwarecode und der Flut an täglich eintreffenden Sicherheits-Alerts Herr zu werden.

Sicherheitslücken mehr als verdreifacht

Zusätzlich gibt es immer noch eine zu große Wissenslücke zwischen dem, was Unternehmen in ihrer Software vermuten, und was sich tatsächlich in ihr befindet. Um den Umfang an undokumentierter Open Source Software (OSS) in Unternehmen zu erfassen und potenzielle Compliance- und Sicherheits-Risiken zu identifizieren, werteten Analysten in einer aktuellen Studie zur Software Supply Chain mehr als 2,6 Milliarden Codezeilen aus. 83% der in den Audits aufgedeckten Risiken war den Unternehmen im Vorfeld der Untersuchung nicht einmal bekannt.

Insgesamt entdeckten die Audit-Teams 230.000 kritische Fälle. Das sind im Durchschnitt alle 11.500 Codezeilen ein Compliance-Verstoß, eine Sicherheitsschwachstelle oder Ähnliches. Die Zahl der Sicherheitslücken auf Codeebene hat sich im Vergleich zum Vorjahr mehr als verdreifacht. Pro Audit wurden durchschnittlich 282 Schwachstellen entdeckt, ein Anstieg von 217% (2021: 89). Von den aufgedeckten Schwachstellen stellten 27% ein „hohes“ CVSS-Risiko (Common Vulnerability Scoring System) dar und damit eine unmittelbare Bedrohung für IT-Sicherheit und Cyberschutz.

Ohne SBOM, kein Geschäft

Da der Anteil an OSS in Anwendungen kontinuierlich wächst und auch die durchschnittliche Anzahl an Abhängigkeiten weiter steigt, drängt die Zeit für Softwareanbieter, hinsichtlich ihres Open Source-Monitoring und -Mediation einen Gang höher zu schalten und beispielsweise Software Composition Analysis über den gesamten IoT-Stack hinweg durchzuführen. Entsprechende Tools geben 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.

Die vollständige Dokumentation aller eingesetzten Komponenten einschließlich Lizenzierung, Versionen und Herkunft ermöglicht es, Auswirkungen von Schwachstellen und Exploits auf die eigenen Software zu untersuchen – und zwar schnell und gezielt. Die Software Bill-of-Material (SBOM) hat sich daher nicht ohne Grund in den letzten Jahren zum Kernelement der Open Source-Governance etabliert. Sie gilt als zentraler Bestandteil von Compliance-Programmen und wird auch von vielen großen Unternehmen mittlerweile beim Kauf von Softwareprodukten als Teil der SLA vertraglich festgesetzt.

OSS-Standards und Initiativen

Wer zum Beispiel als Softwareanbieter mit der US-Regierung Geschäfte machen will, muss seit Mai 2021 nach einer Executive Order eine Software-BOM für jedes Produkt bereitstellen und automatisierte Tools und Prozesse zur Überprüfung der Code-Integrität implementieren. Die EU-Kommission geht mit ihrer Open-Source-Software-Strategie 2020-2023 in eine ähnliche Richtung. Auch einflussreiche Branchenverbände und Behörden wie die FDA (The Food and Drug Administration) in den USA sowie die GENIVI Alliance und die Automotive Grade Linux (AGL) machen sich für die SBOM stark.

Parallel dazu verbessert sich zunehmend das Framework rund um die automatisierte und kollaborative Erstellung der Software-BOM. So haben sich branchenweit anerkannte Standardformate etabliert, die Entwicklern und Anbietern helfen, Informationen entlang der Software Supply Chain weiterzugeben und zu vereinheitlichen. Dazu gehören allen voran SPDX (Software Package Data Exchange), CycloneDX und SWID (SoftWare IDentification). Seit Dezember ist zudem das OpenChain-Projekt nun auch ISO-zertifiziert (ISO/IEC 5230:2020). In Verbindung mit ISO/IEC 27001 – dem De-facto-Standard für das Management von Sicherheit in Informationssicherheits-Managementsystemen (ISMS) – erlaubt es einen ganzheitlichen Blick auf Software-Assets.

Sichere Software Supply Chain – Best Practices

Im Zusammenhang mit OSS die Vogel-Strauß-Taktik anzuwenden und den Kopf in den Sand zu stecken, ist angesichts dieser Entwicklungen keine Lösung. Softwareanbieter stehen in Sachen OSS-Governance heute stärker in der Verantwortung denn je. Die Aufgabe von Entwicklern ist es, Software zu entwickeln. Es sind die Unternehmen, die gemeinsam mit Rechtsexperten, Produktmanagern und Sicherheitsteams für Sicherheit und Compliance beim Umgang mit Open Source Software sorgen müssen. Grundsätzlich haben sich dabei folgende Best Practices bewährt:

Transparenz in der Software-Pipeline ist die Grundvoraussetzung, um zu verstehen, von woher Komponenten und Pakete Eingang in den Code und damit in den Anwendungen finden.
Das Erstellen einer SBOM ist komplex und erstreckt sich über mehrere Phasen hinweg. Neben Top-Level-Komponenten, Sub-Komponenten und Bundle Packages müssen auch direkte und transitive Abhängigkeiten sowie die dazugehörigen Lizenzen enthalten sein. Ergänzt wird die SBOM durch sogenannte Snapshot Reports, die jederzeit ein aktuelles Bild der Sicherheitslage liefern.
Shift-Left: OSS-Risiken lassen sich proaktiv entschärfen, wenn das Vulnerability Management sowie die Lizenz-Compliance bereits früh in der Entwicklungsphase aktiv betrieben wird. Dazu gehört auch die Integration von OSS-Scanning in dem Built-Prozess von Anwendungen.
Software Composition Analysis(SCA)-Tools bieten den nötigen Automatisierungsgrad, um sowohl Sicherheits- als auch Compliance-Risiken im Softwarecode schnell und sicher aufzuspüren. Entsprechende Audits sollten kontinuierlich durchgeführt werden.
Das Open Source Program Office (OSPO) versammelt Vertreter aus den Bereichen Recht, Technik, Produkt und Sicherheit kommen darin zusammen, um eine ganzheitliche Open Source-Strategie zu entwickeln und zu implementieren. Darüber hinaus stellen sie die Rahmenbedingungen, um Code innerhalb von Open-Source-Projekte in die Community einzubringen.
Open Source Review Boards (OSRBs) sind ein weiterer guter Ansatz, um Rechts-, Entwicklungs-, Sicherheits-, IT- und Führungsteams an einen Tisch zu bringen, Richtlinien festzulegen und Leitfäden zu erstellen. Ihre Aufgabe besteht darin, die Prozesse kontinuierlich zu verfeinern, mit dem die Entwicklungsteams Open-Source-Code und anderen Code von Drittanbietern in Produkte und Projekte einbinden.
OSS-Experten fallen nicht vom Himmel. Unternehmen sollten langfristig in die Aus- und Weiterbildung ihrer Mitarbeiter investieren. Hier empfiehlt sich die branchenweite Zusammenarbeit mit anderen Unternehmen. Auch Open-Source-Management-Schulungen, wie sie von der Linux Foundation angeboten werden, können wichtige Impulse setzen.
Dezidierte Teams und definierte Prozesse für die OS-Governance sind das eine. Etwas anderes ist es, die Richtlinien und Best Practices auch in der Praxis umzusetzen. Dazu brauchen die Teams Unterstützung auf C-Level.

Softwareanbieter, die diesen Best Practices folgen und sich aktiv über Verbände und Initiativen in die Open-Source-Community miteinbringen, tragen nicht nur zur lückenlosen Transparenz der Software Supply Chain bei. Sie sind auch in der Lage, auf Anfragen ihrer Kunden zu Sicherheitslücken und Compliance-Verstößen schneller zu reagieren und Risiken zuverlässiger zu entschärfen.

Über die Autorin:

Nicole Segerer blickt auf über 15 Jahre Erfahrung in den Bereichen Softwareproduktstrategie und Marketing zurück. Bei ihr dreht sich alles um die Analyse von Softwareprodukten und damit den Mehrwert der Lösungen sowie das Kundenerlebnis zu steigern. Als Vice President Product Management & Marketing bei Revenera unterstützt sie Softwareanbieter und IoT-Hersteller bei der Umstellung auf neue digitale Geschäftsmodell und der Optimierung der Softwaremonetarisierung.