Die Software-Branche braucht Software Bills of Materials Open Source kommt in Zukunft nicht ohne SBOM aus

Ein Gastbeitrag von Dieter Kehl 4 min Lesedauer

Anbieter zum Thema

Open Source Software (OSS) spielt eine immer wichtigere Rolle bei der Entwicklung von Geschäftsanwendungen. Allerdings geht damit auch ein ernst zu nehmendes Sicherheitsrisiko einher, dem sich Unternehmen mithilfe einer Software Bills of Materials (SBOM) sowie eines effizienten SBOM- und SBOM-Vulnerability-Managements stellen können.

In einer Welt, in der Software-Entwickler die Codebasen von Dritten nutzen, um Zeit zu sparen, ist Transparenz der Schlüssel zu mehr Sicherheit.(Bild:  deagreez - stock.adobe.com)
In einer Welt, in der Software-Entwickler die Codebasen von Dritten nutzen, um Zeit zu sparen, ist Transparenz der Schlüssel zu mehr Sicherheit.
(Bild: deagreez - stock.adobe.com)

Die Zeiten von vollständig selbstgeschriebenem Programmcode sind vorbei. Stattdessen hat sich Open Source Code in der Software-Entwicklung das Rampenlicht gesichert und ist mittlerweile allgegenwärtig. Das bestätigte auch der aktuelle The State of Open Source Report von OpenLogic, der zeigte, dass 84 Prozent der untersuchten Codebasen mindestens eine Open-Source-Komponente enthalten.

Gleichzeitig bedeutet das, dass Unternehmen zunehmend mit Anwendungen arbeiten, die sich zum Teil aus Open-Source-Bausteinen zusammensetzen. So zeigen sich laut des aktuellen Open Source Monitor von Bitkom 53 Prozent der befragten Unternehmen aufgeschlossen gegenüber Open Source Software (OSS); 69 Prozent nutzen sie aktiv.

Das Spiel mit dem Open-Source-Feuer

Für Entwickler ist die breite Vielfalt an Open-Source-Bibliotheken eine praktische Code-Quelle. Durch sie können Unternehmen die Software-Entwicklung beschleunigen und gleichzeitig anfallende Kosten, zum Beispiel für teure Lizenzen, senken. Allerdings fand OpenLogic auch heraus, dass 89 Prozent der Codebasen mindestens eine Open-Source-Schwachstelle aufweisen. Der Anteil der Codes, die hochriskante Lücken, zum Beispiel in Form bekannter Exploits, beinhalten, ist innerhalb eines Jahres um 20 Prozent gestiegen und liegt nun bei 15 Prozent. Das Durchschnittsalter von Open-Source-Schwachstellen beträgt 4,4 Jahre. Zudem konnte festgestellt werden, dass viele Codebasen über lange Zeiträume hinweg nicht aktualisiert wurden.

Dabei haben die letzten Jahre gezeigt, dass Cyberangriffe auf anfällige Open-Source-Komponenten gar nicht so gefahrlos sind. So fanden Akteure Ende 2020 ein Hintertürchen in die Netzwerk-Monitoring-Plattform von SolarWinds, die wiederum von anderen Sicherheits-Tools verwendet wird. 2021 wurde eine kritische Sicherheitslücke in der Java-Bibliothek Log4j entdeckt. Das verheerende dabei: Die Anzahl an Java-Anwendungen, die diese Komponente nutzten und sich somit angreifbar machten, war unermesslich.

Unternehmen müssen somit Herr über das Problem von potenziellen Sicherheitslücken in Drittanbieter- und/oder Open Source Code werden. Dazu gilt es zunächst einmal zu verstehen und nachzuvollziehen, welche Software in ihrer IT-Landschaft zum Einsatz kommt und worauf die jeweiligen Lösungen aufbauen. Dafür eignet sich am besten eine Software Bill of Materials (SBOM).

Eine detaillierte „Zutatenliste“

Wer sich gesund und ausgewogen ernähren möchte, schaut vor dem Kauf in der Regel auf die Liste der Inhalte und Nährstoffe von Lebensmitteln. Im Prinzip ist eine SBOM nichts anderes als eine „Zutatenliste“, aus denen sich Anwendungen und Systeme zusammensetzen. Sprich: Eine SBOM zählt alle Komponenten – einschließlich aller kommerziellen Bestandteile sowie der verwendeten Open-Source-Bibliotheken – eines Software-Produkts auf. Darüber hinaus beschreibt sie die Beziehungen der Komponenten untereinander innerhalb der Software-Lieferkette. Diese Transparenz spielt besonders in Sachen Sicherheit eine entscheidende Rolle.

Ähnlich wie bei den Inhaltsstoffen von Lebensmitteln fungiert die SBOM als Entscheidungsgrundlage für Unternehmen, da diese genaustens nachvollziehen können, welche Komponenten sie in ihrem Stack einbinden. Für Software-Entwickler ergeben sich mit einer SBOM zudem noch weitere wichtige Vorteile. So dient sie als wichtiges Hilfsmittel im Kampf gegen Cyber-Kriminelle, die Code-Schwachstellen gezielt angreifen. Die Auflistung aller Software-Komponenten und Abhängigkeiten gibt Entwicklern Aufschluss darauf, ob sich in ihrem (Open Source) Code bekannte oder potenzielle Sicherheitslücken befinden.

Dank der detaillierten Aufschlüsselung können Entwickler zudem genaustens nachvollziehen, welche Versionen der jeweiligen Komponenten in die Software eingeflossen sind. Das vereinfacht die Installation von Updates und Patches enorm. Falls es zum Beispiel zu einer Warnmeldung oder einem Rückruf bestimmter Komponenten kommt, müssen Entwickler schnell herausfinden, wo diese verbaut sind. Mithilfe einer SBOM lassen sich die betroffenen Bestandteile exakt und auf direktem Wege ausfindig machen. Darüber hinaus hilft die Stückliste Entwicklern dabei, den Überblick über Drittanbieter-Code-Lizenzen zu behalten.

Den vollen Durchblick behalten

Damit Software-Lieferketten noch sicherer werden, folgte das Bundesamt für Sicherheit in der Informationstechnik (BSI) 2023 dem Beispiel der Biden-Regierung. Diese hatte zwei Jahre zuvor im Rahmen der Executive Order on Improving the Nation’s Cybersecurity veranlasst, dass Käufern von Software-Produkten eine SBOM bereitgestellt werden muss. Das BSI veröffentlichte mit Teil zwei der Technischen Richtlinie TR-03183 seine eigenen Vorgaben an die Erstellung und Gestaltung solcher Stücklisten. Die Richtlinie gibt unter anderem die Datenfelder vor, die in einer SBOM enthalten sein müssen. So sind zum einen Informationen zur Aufzeichnung selbst wie der Ersteller der SBOM sowie ein Zeitstempel notwendig. Zum anderen müssen alle relevanten Daten zu sämtlichen Komponenten angegeben werden – darunter deren Ersteller, Name und Version, Abhängigkeiten, Lizenzen sowie kryptografisch sichere Hashwerte.

Jetzt Newsletter abonnieren

Täglich die wichtigsten Infos zur IT-Sicherheit

Mit Klick auf „Newsletter abonnieren“ erkläre ich mich mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung (bitte aufklappen für Details) einverstanden und akzeptiere die Nutzungsbedingungen. Weitere Informationen finde ich in unserer Datenschutzerklärung. Die Einwilligungserklärung bezieht sich u. a. auf die Zusendung von redaktionellen Newslettern per E-Mail und auf den Datenabgleich zu Marketingzwecken mit ausgewählten Werbepartnern (z. B. LinkedIn, Google, Meta).

Aufklappen für Details zu Ihrer Einwilligung

Je mehr Anwendungen ein Unternehmen entwickelt und/oder kauft und je mehr Komponenten die Entwickler von externen Quellen heranziehen, desto größer und unübersichtlicher wird der Datenbestand, der den SBOM zugrunde liegt. Diese Komplexität wird vor allem dann zum Problem, wenn Komponenten akribisch verwaltet, bearbeitet und aktualisiert werden müssen. Unternehmen sollten zunächst die Lösungen nach Einfluss auf den täglichen Geschäftsbetrieb priorisieren, die ein SBOM-Management brauchen. Außerdem sollte das SBOM-Management bereits beim Entwicklungs- und Einkaufsprozess neuer Anwendungen künftig mitgedacht werden. Eine OSS-Vulnerability-Management-Lösung unterstützt zusätzlich bei der Identifizierung von bestehenden Schwachstellen in Open-Source-Komponenten. Wichtig ist, dass auch die SBOM-Daten angepasst werden, sobald die Software aktualisiert oder einzelne Bestandteile verändert werden.

Fazit

Wer sein Haus nicht selbst baut, bleibt häufig darüber im Dunkeln, wie bröckelig und lückenhaft die Bausteine sein könnten. Die Erkenntnis folgt meist dann, wenn es schon zu spät und der Schaden angerichtet ist. Ähnlich verhält es sich auch bei Open Source Code. In einer Welt, in der Software-Entwickler die Codebasen von Dritten nutzen, um Zeit zu sparen, ist Transparenz der Schlüssel zu mehr Sicherheit. Unabhängig von Unternehmensgröße und Branche, empfiehlt es sich deshalb, für alle Anwendungen eine Software Bill of Materials zu erstellen und diese auch langfristig zu pflegen. Als wertvolle Ergänzung liefert sie alle notwendigen Informationen, um die eigene Anwendungslandschaft zu verstehen und effektiv vor Cyber-Akteuren zu schützen.

Über den Autor: Dieter Kehl ist Director Sales DACH/CEE/MEA bei OpenText.

(ID:50256010)