Software Bill of Material hilft beim Verstehen von AppSecWie sich das Beste aus Open-Source-Software herausholen lässt

Die meisten unter uns sind mit der Log4shell-Schwachstelle in der Apache-Logging-Bibliothek vertraut. Die Schwachstelle hat eine Reihe von notwendigen Erkenntnissen befördert, was die Nutzung von Open Source anbelangt. Welche davon sind besonders wichtig?

Die Erfahrung mit Log4Shell hat erneut gezeigt, wie stark Open Source in Unternehmen inzwischen verbreitet ist. Selbst in kommerzieller Software finden sich Open Source-Bestandteile als Abhängigkeiten. Hier hat sich noch deutlicher gezeigt, dass Open Source-Projekte häufig von unentgeltlich tätigen, externen Entwicklern und nicht von eigenen Mitarbeitern oder kommerziellen Drittanbietern erstellt und gepflegt werden.

Die IT hat keinerlei Kontrolle über die Verwendung von Open Source-Software in kommerzieller Software. Selbst dann nicht, wenn sie über ausgereifte Open Source Governance-Prozesse für direkt heruntergeladene und verwendete beziehungsweise im Rahmen der eigenen Softwareentwicklung eingesetzte Open Source-Software verfügt.

Patches und Sicherheits-Updates für Open Source werden nicht automatisch an die Anwender verteilt – sie müssen aktiv abgerufen werden. Und man muss wissen, dass man sie abrufen muss. Die Sache hat nur einen Haken. Wenn man nicht weiß, dass man etwas benutzt, dann weiß man auch nicht, dass und welche Updates man dafür braucht. Manchmal werden Projekte aufgegeben oder nicht mehr weiter gepflegt. Was sollten Unternehmen generell über Open Source wissen, damit sie zukünftig besser vorbereitet sind?

Daher gilt die Regel: Zunächst muss man erkennen, dass und wo man Open Source einsetzt. Von diesem Ausgangspunkt aus, kann man anschließend einen praktikablen Management-Workflow entwickeln. Open Source-Teams wissen nicht, wer ihren Code heruntergeladen hat, und es existiert kein Push-Mechanismus für Updates.

Als Anwender muss man an dieser Stelle selbst aktiv werden. Wenn ein Projekt komplett aufgegeben oder genauer gesagt das Projekt nicht mehr gepflegt wird – wäre es hilfreich, wenn die mit dem Projekt befassten einen entsprechenden Hinweis veröffentlichen. Das geschieht aber in der Regel nicht. Ein weiteres Problem ist die Unterscheidung zwischen einem „aufgegebenen“ und einem „abgeschlossenen“ Projekt. Und die kann nur treffen, wer selbst mit dem Projekt beschäftigt ist. Wenn Sie nicht wissen, dass Sie ein Projekt nutzen, dann stellen Sie sich genau diese Fragen. Dies ist das erste wichtige Puzzleteil, um zu akzeptieren, dass Open Source anders gehandhabt wird und einen entsprechenden Prozess einzuführen.

Besonders schwierig wird es, wenn man zum Beispiel drei oder vier Ebenen tief in der Abhängigkeit beziehungsweise der Lieferantenkette stehen und deshalb nicht unbedingt wissen, dass bei einem Open Source-Code läuft. Das ist eine der wesentlichen Lektionen, die uns Log4j gelehrt hat.
In seiner Präsidialverfügung hat US-Präsident Biden ausdrücklich verlangt, dass von US-Bundesbehörden erworbene Softwareprodukte eine Software-Stückliste (Software Bill of Materials, kurz: SBOM) benötigen. Ähnliche Entwicklungen kann man auch anderswo beobachten.

Unter der Bezeichnung SBOM rangiert im Grunde eine Datei, in der die von einer Applikation genutzten Bibliotheken aufgelistet sind. Sie ist wesentlicher Bestandteil eines Managementplans. Der umfasst nicht nur den Einsatz von Open Source in der Software-Lieferkette, sondern dient auch als Ankerpunkt für andere operative Elemente. Das am häufigsten diskutierte operative Element ist die Nutzung einer SBOM zur Kommunikation der Risiken von Sicherheitslücken in Komponenten der Software-Lieferkette für die jeweilige Anwendung.

Praktisch gesehen, erstellen viele Unternehmen SBOMs einfach in Form einer Stückliste, die besagt: Ich nutze diese Komponenten, die aus dieser Quelle stammen und die diese Version verwenden. Doch das ist eine statische Angelegenheit. Sie bildet ab, wie ein Stück Software zum Zeitpunkt der Auslieferung aussieht. Das ist wichtig, aber kein Allheilmittel zur Behebung von Schwachstellen. Es sagt nichts darüber aus, ob etwas mehr oder weniger sicher ist als irgendetwas anderes. Strenggenommen, sagt es einem nur, aus welchen Komponenten dieses spezielle Stück Software besteht. Die SBOM ist wie gesagt kein Allheilmittel – sie ist Teil eines Workflows, den Unternehmen implementieren sollten. Die Schwierigkeit liegt darin, dass die SBOM-Daten Eingang in den Workflow finden müssen.

Anders gesagt: das über SBOMs vermittelte Wissen ist wertvoll. Aber wenn Unternehmen keinen Prozess für den Umgang damit haben, dann haben eine SBOM und die damit verbundenen Informationen über Schwachstellen nur minimalen Nutzen. Wenn ein definierter Prozess fehlt, liegt hier das größte Problem. Sonst endet die SBOM als eine Datei mehr in einem Verzeichnis.“

Ein Beispiel soll verdeutlichen, wie so ein Prozess aussehen kann: Alle Unternehmen haben eine IT-Abteilung, die für das Einpflegen von Software-Patches zuständig ist. Jede Software setzt sich aus verschiedenen Komponenten zusammen. Aus dem Synopsys OSSRA-Report weiß man, dass die Open Source-Nutzung innerhalb von kommerzieller Software im Schnitt bei 78 Prozent liegt. Verantwortliche wissen also, dass es diese Open Source-Komponenten gibt, und dass sie aktuell gehalten werden müssen. Genau diese Informationen liefert eine SBOM, wenn man sie dem von der IT verwalteten Asset beifügt.

Wenn zu irgendeinem Zeitpunkt eine neue Schwachstelle aufgedeckt wird, kann die IT das SBOM-Management-System befragen und feststellen: Aha, das liegt vor, und wo bekomme ich jetzt meinen Patch her?  Den Patch bekommt man von dort, wohin die Herkunftsinformation in der SBOM verweist. Darin besteht ihre Aufgabe. Sie soll Ihnen nicht sagen, dass es eine neue Schwachstelle gibt – das ist ein separater Workflow, ein separater Satz von Mechanismen. Sie ist vielmehr ein Dokument, das genau beschreibt, was sich in dem Artefakt befindet, das Sie betreiben wollen. Das ist nur einer von vielen weiteren möglichen Workflows.

Generell sollte eine SBOM bestimmte Anforderungen erfüllen. Wenn sie hilfreich sein soll, muss eine SBOM sowohl genau, als auch vollständig sein. Das sind zwei verschiedene Probleme, wobei die Lösung des einen von der Lösung des anderen abhängt. Damit eine SBOM vollständig ist, müssen zunächst einmal alle innerhalb einer Applikation paketierten externen Bibliotheken verzeichnet sein.

Dazu gehören Open Source Software, kommerzielle Bibliotheken von Dritten und jegliche über Drittverträge eingebrachte Software. Idealerweise würde man die SBOM aus dem Quellcode einer Applikation beziehen, was aber je nach Auslegung des Build-Prozesses der Applikation schwierig sein kann. Beispielsweise würden Sie zwei verschiedene SBOMs brauchen, wenn Sie eine Applikation für zwei verschiedene Plattformen kompilieren – eine für Windows und eine für Linux.

Ebenso wichtig ist, dass die Komponenten genau identifiziert werden – mit allen verfügbaren Informationen von der Herkunft bis hin zur verwendeten Version. Eine First-Party-SBOM, die sich aus dem Quellcode der Anwendung speist, ist am genauesten. Es gibt aber auch SBOMs von Drittanbietern. In diesem Fall wird die Applikation und nicht der Quellcode untersucht. Das kann dazu führen, dass einige Informationen fehlen, weil Sie die Version der Bibliothek nicht exakt bestimmen können. Diese Methode eignet sich daher nur, wenn keine First-Party-SBOMs verfügbar sind, oder als zusätzliches Instrument zur Überprüfung der First-Party-SBOM.

Die Ära der SBOMs hat allerdings gerade erst begonnen. Die meisten Anbieter arbeiten noch an der Erstellung von SBOMs, und das wird auch in absehbarer Zukunft noch der Fall sein. Eine SBOM ist zwar ein Indikator für das Verständnis von Open Source-Sicherheit, aber es nicht der einzige.
Wenn ein Unternehmen von einem Anbieter eine SBOM verlangt, aber nicht über einen Workflow zu deren Verarbeitung und Nutzbarmachung verfügt, dann produziert das zusätzliche Kosten, ohne dass daraus ein Nutzen erwächst. Interessanterweise haben viele noch nicht bemerkt, dass die Anwendungsfälle für SBOMs oft dem entsprechen, was Software Composition Analysis (SCA)-Lösungen bereits bieten.

Den größten Nutzen liefern SBOMs, wenn sie Bestandteil einer generellen Strategie zur Risikominderung sind. Die Voraussetzung ist, dass Firmen über ein Verfahren verfügen, mit dem sie die Risiken messen können, die eine SBOM konstatiert hat. Ebenso wie Verfahren, mit denen sich die Risiken senken lassen.“

Tim Mackey ist Principal Security Strategist bei Synopsys.

Synopsys