Gastbeitrag Höhere Produktivität, schnellere Time-to-Market und geringere Kosten – die Liste der Vorteile von Open Source Software (OSS) ist lang. Nicht ohne Grund machen OSS-Komponenten heute bis zu 50 Prozent des Codes kommerzieller Software aus. Die gängige Nutzung kann jedoch nicht darüber hinwegtäuschen, dass gerade hinsichtlich Management und Compliance noch Verbesserungsbedarf besteht. So stieß Revenera bei der Untersuchung von mehr als 2,6 Milliarden Codezeilen auf insgesamt 80.157 kritische OSS-Komponenten. Der Anstieg um 80 Prozent ist unter anderem auf die Anzahl der verwendeten Node.js-Pakete aus NPM-Modulen zurückzuführen. Durchschnittlich fand sich alle 32.600 Codezeilen ein Compliance-Verstoß, eine Schwachstelle oder Ähnliches. Das Erstaunliche: Obwohl sich 45 Prozent der in den Audits untersuchten Codebasis aus Open-Source-Komponenten zusammensetzten, wussten die Unternehmen vor Beginn des Auditprozesses gerade einmal von 1 Prozent dieser Komponenten.
Woher kommt diese mangelnde Transparenz beim Umgang mit OSS? Die Gründe dafür sind unterschiedlich. So setzt sich Software in der Regel aus unterschiedlichen Komponenten zusammen, die darüber hinaus aus verschiedenen Quellen stammen – angefangen bei proprietären Code über Code von Partnern und Drittanbietern bis hin zu Open Source-Repositories im Netz.
Neben Paketen und Abhängigkeiten müssen dabei auch Subkomponenten, Binärdateien ohne Manifest-Dateien, Multimedia-Dateien, Bilder/Icons, Codecs und Copy/Paste-Codes – sowie deren jeweiligen Lizenzen – berücksichtigt werden. Open Source birgt damit nicht automatisch mehr Risiken als jeder andere Code. Seine Komplexität jedoch macht eine genaue Dokumentation und ein durchgängiges Management entlang der Supply Chain extrem schwierig.
Wer glaubt über die Nutzung von OSS-Komponenten im eigenen Unternehmen auf dem aktuellen Stand zu sein, sollte folgende Fragen problemlos beantworten können. Wer hat den Code geschrieben? In welchen Anwendungen und IoT-Geräten wird dieser eingesetzt? Gibt es bei diesem Code Probleme bei der Sicherheit oder der Compliance? Und konnten diese Probleme gelöst werden? Einfache Antworten auf diese Fragen gibt es nicht, auch weil nicht alle OSS-Risiken für alle gleichermaßen relevant sind. Während die Rechtsabteilung besonderes Augenmerk auf die Compliance eines Softwareprodukts legt, muss in der Software Supply Chain klar sein, welche Open-Source/kommerzielle Pakete in den Binärdateien enthalten sind. Das Entwicklerteam wiederum konzentriert sich auf die fristgerechte Auslieferung eine Produkts, während das Sicherheitsteam mit dem Software Vulnerability Management beschäftigt ist.
Es überrascht daher nicht, dass Initiativen rund um Open Source in den letzten Jahren immer wieder versucht haben, entlang der Software Supply Chain einheitliche Verfahren zu etablieren. Rechtlich verbindliche Richtlinien zum Umgang mit OSS, ihrer branchenübergreifende Adoption sowie eine kontinuierliche Kontrolle der Vorgaben gibt es jedoch bislang nicht bzw. nur in Ansätzen. Softwareanbietern, IoT-Herstellern und Tech-Unternehmen bleibt es weitgehend selbst überlassen, wie sie OSS in ihren Produkten managen und innerhalb der Software-Lieferkette mit Partnern, Auftragnehmern und der Open Source-Community agieren. Das heißt jedoch nicht, dass es gänzlich an Standards und Empfehlungen fehlt.
Software Package Data Exchange (SPDX) beschreibt ein Standardformat, das von einer Arbeitsgruppe der Linux Foundation im Rahmen des „Open Compliance Program“ entwickelt und 2011 eingeführt wurde. SPDX soll das Handling von OSS vor allem in Hinblick auf Lizenzen und Copyrights vereinfachen. Im SPDX-Format werden dabei alle Informationen zum Softwarepaket sowie die Lizenz- und Urheberrechtsinformationen auf Paket- und Dateiebene eindeutig gelistet. Darüber hinaus liefert SPDX Metadaten über Verfasser des Codes und Zeitpunkt der Programmierung.
Mit dieser Transparenz hat SPDX viel dazu beigetragen, das Vertrauen in Open Source zu stärken und die Zusammenarbeit zwischen Anbietern zu vereinfachen. Die konsistente Notation von Informationen erleichtert die Automatisierung der Lizenzerfassung und reduziert den Arbeitsaufwand. Ein gutes Beispiel ist hier die BusyBox, die zum Standardwerkzeug vieler Entwickler gehört. Auf Top-Level-Paket läuft dieses Programm unter der General Public License (GNU GPL). Untersucht man das Tool jedoch genauer, finden sich in den unteren Ebenen knapp 800 Dateien, deren Lizenzen von GPL abweichen. Mit SPDX können Entwickler solche abweichenden Lizenzen leichter erkennen und sämtliche Lizenzen auf Dateiebene in einer einzigen Datei zusammenzufassen, um Unklarheiten auszuräumen.
OpenChain ist ein weiteres Open-Source-Projekt der Linux Foundation. Auch hier lautet das Ziel, das Vertrauen zwischen Unternehmen innerhalb der Software Supply Chain durch das Einhalten bestimmter Standards zu stärken. Zu den hochrangingen Mitgliedern gehören unter anderem Microsoft, CISCO, Google und Adobe. Das Projekt stellt ein Framework für die Nutzung von OSS bereit und unterstützt Unternehmen dabei, die Grundvoraussetzungen für ein internes Qualitätssicherungsprogramm zu schaffen. Eine feste Vorgehensweise ist dabei nicht vorgeschrieben. Vielmehr werden Best Practices beschrieben, die Unternehmen zeigen, wie sich ein grundlegendes Open-Source-Compliance-Programm implementieren lässt.
Gleichwohl hält OpenChain an einigen Grundregeln fest. Dazu gehört die Entwicklung von Open-Source-Richtlinien, entsprechende Schulungen für Entwickler, Rechts- und Sicherheitsteams sowie Dritte, und schließlich die eindeutige Zuweisung von Rollen und Verantwortlichkeiten. Eine wichtige Rolle kommt auch der Software-Bill-of-Materials (BOM oder SBOM) zu, die es einmalig zu verifizieren und im weiteren Verlauf regelmäßig zu kontrollieren und anzupassen gilt – und zwar für jede neue Version einer Software.
Die BOM ist ein aktuelles Verzeichnis aller eingesetzten Komponenten einer Software sowie deren Abhängigkeiten. Was einfach klingt, ist in der Praxis hochkomplex. Softwareentwickler greifen auf unterschiedliche OSS-Komponenten zurück oder nutzen kommerzielle Komponenten von Drittanbietern, die selbst wieder OSS enthalten. Fehlen hier nur an einer Stelle die nötige Informationen, ist die Dokumentationskette unterbrochen und die einzelnen „Bestandteile“ einer Software lassen sich nur noch schwer zurückverfolgen.
Auch wenn die Umsetzung der BOM noch an vielen Stellen zu wünschen übriglässt, hat sich die Stückliste in den letzten Jahre in der Branche etabliert. So gilt sie in den meisten Open Source-Initiativen als Kernelement von Compliance-Programmen und wird dementsprechend häufig auch in die Vertragsvereinbarungen mitaufgenommen. Die FDA (The Food and Drug Administration) kündigte bereits in einem Bericht an, die Einführung von BOM im Rahmen einer Pre-Market-Submission für medizinische Geräte zu prüfen. Langfristig scheint es also, dass die BOM zum Pflichtprogramm wird.
So vielversprechend diese Entwicklungen und Initiativen auch sind – noch fehlt es an verbindlichen Auflagen und Standards. Beides wird dringend benötigt. Eine fehlerhafte oder unvollständige Stückliste in der langen Reihe an Softwareentwicklern und -anbietern kann alle Compliance-Bemühungen zunichtemachen. Und selbst wenn alle Beteiligten in der Software Supply Chain ihre OSS-Komponenten lückenlos festhalten und weitergeben, bleibt die Frage nach einem standardisierten Format. Andernfalls gestaltet sich die die Konsolidierung von Daten und die Einbindung in die automatisierte Management- und Scanning-Tools.
Überhaupt fehlt es vielen Unternehmen noch an Lösungen, die Open Source automatisiert scannen und Sicherheitslücken sowie Compliance-Verstöße zuverlässig identifizieren. Baseline-Audits und Fast Scans liefern hier nur unzureichende Ergebnisse. Im Rahmen von forensischen Audits konnte Revenera beispielsweise pro Audit durchschnittlich sechs Prozent mehr Compliance-Risiken entdeckt als bei Standard-Audits. Software Composition Analysis (SCA)-Tools hingegen decken nicht nur auf, welche Source Libraries von den Entwicklern genutzt werden, sondern auch welche Drittanbieter-Bibliotheken standardmäßig damit verknüpft sind. Dabei lässt sich der genaue Anteil des übernommenen Codes innerhalb des proprietären Quellcodes prozentual bestimmen.
An der Integration von OSS-Scanning in den Built-Prozess von Anwendungen und der Implementierung eines Compliance-Programm führt langfristig kein Weg vorbei. Umso wichtiger ist daher, klare Richtlinien und Standards zu vereinbaren, um Sicherheits- und Compliance-Lücken in der Software Supply Chain langfristig zu schließen.
Vor COVID-19 war Remote-Work für viele Unternehmen fast undenkbar. Heute haben sie erkannt, dass es sehr gut funktionieren kann, wenn die Rahmenbedingungen stimmen. Erfahren Sie in diesem Webinar, wie Sie mit der Kollaborationslösung Slack auf die veränderten Arbeitsbedingungen optimal reagieren können.
OutSystems-Studie: 62 Prozent der Befragten haben Sicherheits- und Governance-Bedenken bei Softwareentwicklung mit KI-Unterstützung.
Der Cybersecurity Report von Hornetsecurity stuft 2,3 Prozent der Inhalte gar als bösartig ein. Die…
Die Hintermänner haben es auf Zugangsdaten zu Microsoft Azure abgesehen. Die Kampagne ist bis mindestens…
Cloud-Plattform für elektronische Beschaffungsprozesse mit automatisierter Abwicklung elektronischer Rechnungen.
Mindestens eine Schwachstelle erlaubt eine Remotecodeausführung. Dem Entdecker zahlt Google eine besonders hohe Belohnung von…
Nur rund die Hälfte schaltet während der Feiertage komplett vom Job ab. Die anderen sind…
