Open-Source-Sicherheit: Automatisierung nötig

Immer mehr Unternehmen nutzen Open-Source in proprietären Anwendungen. Deshalb müssen sie in der Lage sein, die Komplexität solcher Mischumgebungen mit Automatisierungstools zu bewältigen. Nur so  können sie schnell auf neue Schwachstellen reagieren.

Nahezu jede intern entwickelte Software enthält heute Open-Source Komponenten, so Phillip Ivancic, Synopsys Software Integrity Group. Laut dem Bericht 2022 Open Source Security and Risk Analysis des Sicherheitsanbieters enthielten 97 % der kommerziellen Codebasen zumindest einige Open-Source-Codes. Davon waren durchschnittlich 78 % des Codes in den Codebases Open Source. In der im Mai veröffentlichten Studie wurden 2.409 kommerzielle Codebasen aus 17 Branchen analysiert.

Die meisten Unternehmen wollen nicht alles von Grund auf neu entwickeln, wenn sie ihre eigene Software konzipieren, sagte Liu Yang, Mitbegründer und CEO von Scantist. Es gebe inzwischen viele gut etablierte Bibliotheken und Codebasen in Open-Source-Software (OSS), auf die Unternehmen zurückgreifen und aufbauen.

Andrew Martin, Databricks, pflichtete ihm bei und fügte hinzu, dass Open Source es Unternehmen ermögliche, schneller zu voranzuschreiten und bereits verfügbare Codes zu nutzen, anstatt Ressourcen für die interne Entwicklung proprietärer Software aufzuwenden. Open-Source-Technologien gewährleisten außerdem volle Transparenz und Einsicht in den Quellcode und bieten Datenteams eine Verbindung zur breiteren Open-Source-Community, so Martin.

Allerdings bedeutet die Nutzung von Open Source, dass jede Schwachstelle in den Codes von der Host-Unternehmensanwendung übernommen werden könne. Open-Source-Schwachstellen sollten daher immer zuerst behoben werden. Andernfalls könnten Unternehmen, die nicht über solche Schwachstellen informiert sind und ihre Software nicht entsprechend aktualisieren, ernsthafte Sicherheitsrisiken eingehen.

Die Synopsys-Studie ergab, dass 81 % der Software-Codes mindestens eine bekannte Open-Source-Schwachstelle enthielten, was einem Rückgang von 3 % gegenüber dem Vorjahr entspricht. Die Nutzung von Open Source bedeute zwar nicht, dass firmeneigene Software weniger sicher sei, aber sie bringe wichtige Überlegungen mit sich, die angesprochen und verwaltet werden müssten, so Ivancic. Zum einen sollten Unternehmen alle OSS-Komponenten kennen, einschließlich der tatsächlichen Versionen, die in der Codebasis ihrer Projekte verwendet wurden.

Dieses als Software Bill of Materials (SBOM) bezeichnete zentrale Repository sollte sicherstellen, dass Unternehmen in der Lage sind, schnell zu reagieren, wenn neue Schwachstellen aufgedeckt werden, wie z. B. die im vergangenen Jahr bekannt gewordene Zero-Day-Schwachstelle Log4j. Mit einem SBOM sind Unternehmen in der Lage, Anwendungen zu identifizieren, die anfällig sind, und die notwendigen Abhilfemaßnahmen zu ergreifen.

Außerdem müssten sie die genaue OSS-Codebasis kennen, die in einem bestimmten Projekt verwendet wird, um feststellen zu können, ob die Anwendung betroffen ist, wenn neue hochriskante Schwachstellen entdeckt werden. Insbesondere die Log4j-Zero-Day-Schwachstelle werde in den kommenden Jahren aufgrund der zunehmenden Verwendung von OSS wahrscheinlich weitere Schwachstellen hervorbringen.

Darüber hinaus ist die Java-Bibliothek für die Protokollierung von Fehlermeldungen in Anwendungen ein grundlegendes Framework, das von der Hälfte der Java-Anwendungen verwendet werde. Hacker könnten den Log4j-Fehler ausnutzen, um Remote-Angriffe durchzuführen und die OSS-Bibliothek eines Unternehmens zur Kontrolle seiner Systeme zu verwenden. Aber aufgrund der vielschichtigen Natur der OSS-Entwicklung ist es schwierig, mit solchen Schwachstellen umzugehen.

„Wenn Sie eine OSS-Bibliothek für eine Anwendung verwenden, nutzt diese Bibliothek wahrscheinlich eine zweite Bibliothek und diese wiederum eine dritte Bibliothek“, erklärte Liu. „Wenn die dritte Bibliothek eine kritische Schwachstelle aufweist und Sie die erste Bibliothek verwenden, gibt es eine inhärente Schwachstelle in dieser Abhängigkeitskette. Das kann für Sie ein Sicherheitsrisiko darstellen, auch wenn Sie die dritte Bibliothek nicht verwenden.“

Die Identifizierung aller passiven und indirekten Abhängigkeiten sei alles andere als einfach, und es könne für Unternehmen schwierig sein, Sicherheitsexperten für solche Arbeiten zu finden. Er wies auf den Bedarf an automatisierten Tools zur Unterstützung solcher Sicherheitsbewertungen hin.

Ivancic betonte, dass Unternehmen die mit der Verwendung von Open-Source-Codes verbundenen Betriebs- und Lizenzierungsrisiken verstehen müssen. So wies er beispielsweise darauf hin, dass OSS-Codebasen, die nicht über eine aktive Gemeinschaft von Mitwirkenden verfügen, auf potenzielle Risiken hinweisen könnten, da neue Schwachstellen möglicherweise nicht rechtzeitig aufgedeckt und gepatcht werden.

Die Synopsys-Studie ergab, dass 88 % der Codebases Komponenten verwendeten, die nicht der neuesten Version entsprachen, während 84 % Open-Source-Code enthielten, der mehr als vier Jahre veraltet war. Darüber hinaus gab es bei 53 % der geprüften Codebases Lizenzkonflikte, und 20 % enthielten Open Source ohne Lizenz oder mit einer benutzerdefinierten Lizenz.

Ivancic wies darauf hin, dass Open-Source-Projekte über verschiedene Lizenzbestimmungen verfügten, die von sehr freizügig bis hin zu solchen reichten, die von den Nutzern verlangen könnten, abgeleitete Werke unter denselben Lizenzbedingungen zu veröffentlichen. Eine SBOM würde es den Unternehmen ermöglichen, die verschiedenen Lizenzbedingungen besser zu verfolgen, sagte er.

„Wenn Unternehmen ihre Schwachstellen-Updates nicht proaktiv pflegen und überprüfen, laufen sie Gefahr, ein leichtes Ziel für Angreifer zu werden“, sagte er. „Wenn sie außerdem die Open-Source-Lizenzen nicht einhalten, riskieren sie Rechtsstreitigkeiten und setzen sich der Bedrohung ihres geistigen Eigentums aus.“

Wie Liu betonte auch Ivancic, wie wichtig es ist, die Entwicklungspipelines zu automatisieren, um die Risiken auf der Grundlage interner Sicherheitsrichtlinien zu mindern. „OSS ist nicht unsicher, aber die Herausforderung liegt in den vielen Versionen und Komponenten, aus denen ein Softwareprojekt bestehen kann“, erklärte er. „Ohne Automatisierung und Prioritätensetzung ist es unmöglich, da mitzuhalten“.

Er wies darauf hin, dass die OSS-Gemeinschaft bei der Behebung von Sicherheitsproblemen und der Bereitstellung von Fehlerbehebungen sehr schnell reagiere, aber Unternehmen, die OSS nutzen, müssten sich mit der Komplexität auseinandersetzen, um sicherzustellen, dass ihre Software über die richtige, aktuelle Codebasis verfügt. Erschwerend komme hinzu, dass die meisten Unternehmen viele Projekte gleichzeitig verwalten müssten, deshalb ist eine ganzheitliche Software-Sicherheitsstrategie erforderlich.

Das US National Institute of Standards and Technology (NIST) bietet ein Rahmenwerk für die Software-Lieferkette an, das Unternehmen bei der Planung ihrer OSS-Sicherheitsmaßnahmen helfen kann. Entsprechende Governance- oder Regulierungsmaßnahmen sind hilfreich, um die allgemeine Sicherheit von Open-Source-Software zu verbessern.

Es gibt unter den Entwicklern Diskussionen über die Risiken von Backdoor-Exploits und bösartigen Codes, was auf die Notwendigkeit einer besseren Governance in Bezug auf Sicherheit und Verantwortung hinweist. Aber Regulierung allein kann nicht alles lösen. Die Unternehmen müssten noch herausfinden, wie sie eine bessere Sicherheit auf kosteneffiziente Weise erreichen könnten.

Laut der Synopsys-Studie gehörte das Internet-of-Things (IoT) zu den größten Nutzern von Open Source, da 100 % der Codebases in diesem Sektor Open-Source-Codes enthielten. Allerdings wurden bei 64 % der IoT-Codebases Schwachstellen festgestellt.

Martin wies darauf hin, dass Open Source nie dazu gedacht war, mit traditionellem proprietärem Code zu konkurrieren. „Heute sind viele Softwareentwickler und Unternehmen bestrebt, Open Source in bestehende Betriebssysteme und Anwendungen zu integrieren“, sagte er.““Dies unterscheidet sich von Inkompatibilitäten, die aufgrund von Unterschieden bei Elementen wie Datenformaten auftreten können. Letztendlich kann die Integration von Open Source erfolgen, solange die Entwicklung vorhanden ist“.

Er fügte hinzu, dass selbst die am stärksten regulierten Branchen, wie der öffentliche Sektor und Finanzinstitute, auf Open Source als den beste Weg setzen, um Innovationen zu fördern, die besten Talente zu rekrutieren und zu halten und eine Technologieplattform