Illustration: Absmeier Geralt
Die Log4shell-Schwachstelle in der Apache-Logging-Bibliothek hat eine Reihe von notwendigen Erkenntnissen befördert, was die Nutzung von Open Source anbelangt. Welche davon besonders wichtig sind erläutert Tim Mackey, Head of Software Supply Chain Risk Strategy, Synopsys.
Die meisten unter uns sind mit der Log4shell-Schwachstelle in der Apache-Logging-Bibliothek vertraut. Welche Erkenntnisse gibt es hinsichtlich Open Source?
Tim Mackey: »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 Sicherheitsupdates 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?
Tim Mackey: »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 müssen Sie 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 Sie zum Beispiel drei oder vier Ebenen tief in der Abhängigkeit beziehungsweise der Lieferantenkette stehen und deshalb nicht unbedingt wissen, dass bei Ihnen 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 Softwarestückliste (Software Bill of Materials, kurz: SBOM) benötigen. Ähnliche Entwicklungen kann man auch anderswo beobachten. Was genau ist eine SBOM?
Tim Mackey: »Eine SBOM ist 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 Softwarelieferkette, 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 Softwarelieferkette 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.« 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 Ihnen 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.«
Wie kann so ein Prozess aussehen?
Tim Mackey: »Ich gebe Ihnen ein Beispiel, 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 wissen wir, dass die Open-Source-Nutzung innerhalb von kommerzieller Software im Schnitt bei 78 % liegt. Sie 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.«
Gibt es bestimmte Anforderungen, die eine SBOM erfüllen sollte?
Tim Mackey: »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.«
Sind Sie der Ansicht, dass Unternehmen allmählich den Wert von SBOMs erkennen? Und wie schätzen Sie die weitere Verbreitung ein, insbesondere bei der Behebung von Open-Source-Schwachstellen und der Risiken innerhalb der Software-Lieferkette?
Tim Mackey: »Die Ära der SBOMs hat 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-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.«
Wir danken Ihnen für das Gespräch.