SBOM: Transparenz und Sicherheit in der modernen Softwareentwicklung

SBOM (Software Bill of Materials) ist ein unverzichtbares Werkzeug in der modernen Softwareentwicklung. Kaum ein Programm entsteht heute völlig neu - meist bestehen Anwendungen aus Dutzenden oder Hunderten von Bibliotheken, Frameworks und weiteren Komponenten. Jede davon spart Zeit, wird aber gleichzeitig Teil der gesamten Sicherheitskette.

SBOM: Die "Zutatenliste" für Software

SBOM macht sichtbar, aus welchen Bestandteilen ein Softwareprodukt besteht. Es handelt sich im Kern um eine detaillierte Auflistung aller Komponenten, ihrer Versionen und Abhängigkeiten. Wird in einer Bibliothek eine Schwachstelle gefunden, ermöglicht diese Liste eine rasche Prüfung, ob und wo der betroffene Baustein verwendet wird - und welche Anwendungen daher aktualisiert werden müssen.

Was ist ein SBOM und warum wird es mit einer Zutatenliste verglichen?

Ein SBOM ist ein strukturierter Überblick aller Komponenten einer Software. Die Abkürzung steht für Software Bill of Materials - in etwa vergleichbar mit einer Zutatenliste auf einer Lebensmittelverpackung: Kunden können nachsehen, was enthalten ist. Genauso zeigt ein SBOM, welche Bibliotheken, Pakete und Module beim Bau einer Anwendung genutzt wurden.

Gerade weil ein Großteil moderner Software auf Fremdcode basiert, ist die Übersicht so wichtig. Die Hauptlogik entwickeln Programmierer selbst - für Netzwerk, Bildverarbeitung, Verschlüsselung, Datenbanken oder Benutzeroberfläche werden oft fertige Bibliotheken eingebunden.

Was bedeutet Software Bill of Materials?

Der Begriff "Bill of Materials" stammt ursprünglich aus der Industrie, etwa dem Automobilbau. Hier gibt es für jedes Modell eine exakte Stückliste aller Teile und Materialien, mit der sich Herkunft und Einsatz einzelner Komponenten nachvollziehen lassen.

SBOM überträgt dieses Prinzip auf Software: Statt Schrauben und Platinen werden Bibliotheken, Abhängigkeiten und Pakete inventarisiert. Ein Webservice nutzt vielleicht ein Framework, eine Verschlüsselungsbibliothek, Datenbanktreiber und viele weitere Pakete - die wiederum eigene Abhängigkeiten mitbringen. So ist die tatsächliche Zahl der Komponenten oft viel größer, als ein Entwickler auf den ersten Blick erkennt. Ein SBOM schafft Transparenz.

Typische Inhalte eines SBOM

Je nach Format und Tool enthält ein SBOM meist diese Informationen:

• Name der Bibliothek oder des Pakets
• Version der Komponente
• Hersteller oder Lieferant
• Eindeutige Paket-IDs
• Lizenzinformationen
• Abhängigkeitsbeziehungen
• Herkunft der Komponente

Die Version ist besonders wichtig: Eine ältere Version kann bekannte Schwachstellen enthalten, die in neueren Releases bereits behoben sind. Auch indirekte (transitive) Abhängigkeiten werden erfasst - manchmal wird eine unsichere Bibliothek nicht direkt, sondern über andere Pakete eingebunden.

Beispiel: Anwendung A nutzt Bibliothek B, die wiederum Bibliothek C einbindet. Auch wenn Entwickler C nie explizit hinzufügen, ist ihr Code Teil des Endprodukts.

Worin unterscheidet sich ein SBOM von einer einfachen Bibliothekenliste?

SBOM ähnelt auf den ersten Blick Abhängigkeitsdateien wie package.json (JavaScript) oder requirements.txt (Python). Diese dienen aber vor allem der Build- und Paketverwaltung: Sie sagen dem System, was es installieren muss.

Ein SBOM hingegen ist standardisiert, maschinenlesbar und für Sicherheits- oder Compliance-Tools gedacht. Neben explizit eingebundenen Abhängigkeiten beschreibt es auch die tiefergehende Struktur des Produkts - quasi eine automatisch analysierbare "Landkarte" der Anwendungskomponenten.

Warum ist SBOM so wichtig für das Schwachstellen-Management?

Einer der größten Vorteile: Mit einem SBOM lässt sich nach Veröffentlichung einer neuen Schwachstelle schnell klären, ob und wo ein Produkt betroffen ist. Ohne SBOM müssten Entwickler alle Abhängigkeiten von Hand prüfen - in großen Systemen eine Mammutaufgabe.

Gerade bei Anwendungen mit vielen Open-Source-Bibliotheken kann eine Schwachstelle in einer kleinen Abhängigkeit stecken, von der nicht einmal das ganze Team weiß. SBOM macht solche Komponenten sichtbar.

Wie kann eine Schwachstelle in einer Bibliothek viele Programme betreffen?

Weit verbreitete Bibliotheken werden von tausenden Projekten genutzt. Wird in Version 3.4 eine gravierende Lücke entdeckt und in 3.4.1 behoben, kann ein Unternehmen mit aktuellem SBOM sofort ermitteln, wo die alte Version im Einsatz ist.

Ohne SBOM müssen Repositories, Abhängigkeitsdateien, Container-Images und mehr geprüft werden - und eine Bibliothek kann in Dutzenden Projekten stecken. Transitive Abhängigkeiten verschärfen das Problem: Eine scheinbar sichere Bibliothek kann eine unsichere Komponente enthalten, ohne dass Entwickler es merken.

Auch das Thema Zero-Day-Schwachstellen zeigt, wie kritisch ein schneller Überblick nach Bekanntwerden neuer Bedrohungen ist.

Wie beschleunigt SBOM die Reaktion auf neue Schwachstellen?

Nach Veröffentlichung einer Sicherheitslücke muss geklärt werden: Wird die betroffene Komponente überhaupt genutzt? In welchen Produkten? Welche Version ist installiert?

Mit einem aktuellen SBOM kann diese Prüfung automatisiert werden. Die Systeme durchsuchen alle Listen nach Namen und Versionen und erstellen eine Übersicht aller potenziell betroffenen Anwendungen.

Gerade in großen Organisationen mit Hunderten internen Diensten vereinfacht das die Kommunikation enorm - der Abgleich erfolgt zentral statt manuell in jedem Team.

Wichtig: Allein die Präsenz einer Komponente heißt noch nicht, dass das Produkt wirklich angreifbar ist. SBOM hilft, die Suchrichtung einzugrenzen, aber die finale Risikobewertung kann weitergehende Analysen erfordern.

SBOM und automatisierte Schwachstellenprüfung

Besonders wertvoll ist SBOM in Kombination mit Schwachstellendatenbanken und automatischen Sicherheitsscannern. Das Prinzip: Die Tools gleichen die Komponenten und Versionen aus dem SBOM mit bekannten Schwachstellen ab. Bei einem Treffer wird das Projekt zur weiteren Prüfung markiert.

So können auch bereits veröffentlichte Programme regelmäßig auf neue Risiken untersucht werden - denn Schwachstellen werden oft erst Monate nach Release entdeckt. Die Prüfung endet also nicht mit der Entwicklung, sondern läuft kontinuierlich weiter.

SBOM ist in diesem Prozess das Inventar: Es beantwortet die Frage "Was steckt in meiner Software?", während die Analyse-Tools ermitteln, welche Komponenten Aufmerksamkeit benötigen.

Wie funktioniert SBOM in der Praxis?

In der Praxis wird ein SBOM meist automatisiert während Entwicklung, Build oder Release erzeugt. Spezielle Tools analysieren das Projekt, erkennen alle genutzten Komponenten und erstellen eine strukturierte Datei. So bleibt der SBOM Teil des normalen Lebenszyklus einer Anwendung - und wird mit jedem Release aktualisiert.

SBOM-Erstellung während Entwicklung und Build

Je nach Tool kann der SBOM auf verschiedenen Ebenen erzeugt werden: durch Analyse der Abhängigkeitsdateien, des fertigen Containers oder direkt aus dem Build-Prozess. Fügt ein Entwickler eine neue Bibliothek hinzu, erkennt das Tool diese bei der nächsten Ausführung automatisch.

Gerade in automatisierten Entwicklungsprozessen lässt sich die SBOM-Generierung fest in CI/CD-Pipelines integrieren - zusammen mit Tests, Build und Sicherheitsprüfungen.

Für jede Version lässt sich ein eigener SBOM speichern. Das ermöglicht die Rückverfolgung der Komponenten auch Monate oder Jahre nach Veröffentlichung.

Komponenten- und Versionsprüfung

Nach Erstellung kann der SBOM an Schwachstellen-Analysetools übergeben werden. Diese extrahieren Namen, Versionen und IDs und gleichen sie mit den Datenbanken bekannter Schwachstellen ab. Die Präzision hängt stark von der Qualität der Daten ab: Nur eindeutig identifizierbare Komponenten führen zu zuverlässigen Ergebnissen.

Was passiert bei einer gefundenen Schwachstelle?

Findet das System eine potenziell gefährliche Komponente, prüft das Team, welche Anwendungen und Versionen betroffen sind und bewertet das reale Risiko. Gibt es eine fehlerbereinigte Version, wird die Abhängigkeit aktualisiert und die Software neu gebaut - mit entsprechend angepasstem SBOM.

Ist noch kein Fix verfügbar, können temporäre Maßnahmen wie das Deaktivieren von Funktionen, Konfigurationsänderungen oder Alternativ-Bibliotheken helfen.

Warum muss ein SBOM ständig aktuell gehalten werden?

Ein SBOM ist nur dann nützlich, wenn er den tatsächlichen Zustand der Software widerspiegelt. Wurde er vor einem Jahr erstellt und seitdem mehrfach geändert, ist er als Sicherheitsgrundlage riskant.

SBOM sollte als Teil jeder Produktversion betrachtet und mit jeder Änderung an Bibliotheken oder Paketen aktualisiert werden. So entsteht eine Versionshistorie, die auch bei alten Releases nachvollzogen werden kann.

SBOM-Formate: CycloneDX und SPDX

SBOM ist kein einzelnes Dateiformat. Damit verschiedene Tools kompatibel sind, haben sich standardisierte Formate etabliert - vor allem CycloneDX und SPDX.

CycloneDX

CycloneDX wurde mit Fokus auf die Sicherheit der Software-Lieferkette entwickelt. Es beschreibt Bibliotheken, Pakete, Services, deren Abhängigkeiten und weitere Metadaten - darunter IDs, Lizenzen, Datei-Hashes und Beziehungen. Besonders nützlich ist die Abhängigkeitskarte, die zeigt, wie Komponenten zusammenhängen.

CycloneDX wird von vielen Tools im DevSecOps- und Sicherheitsumfeld unterstützt.

SPDX

SPDX (Software Package Data Exchange) ist ursprünglich für Lizenz- und Herkunftsmanagement konzipiert worden, eignet sich aber ebenso als SBOM. Es enthält Infos zu Paketen, einzelnen Dateien, Versionen, Autoren und Lizenzen - und ist besonders für große Open-Source-Projekte relevant, bei denen Lizenzkonformität wichtig ist.

Muss ich als Entwickler das Format selbst wählen?

In vielen Projekten gibt das eingesetzte Tool oder die Infrastruktur das Format vor - häufig CycloneDX, manchmal SPDX oder beides. Entscheidend ist, dass der SBOM vollständig und aktuell ist. Bei Bedarf lässt sich ein Format in ein anderes konvertieren, um Kompatibilität zu verschiedenen Systemen zu gewährleisten.

SBOM und Softwaresicherheit: Grenzen und Herausforderungen

Ein SBOM macht Software transparent, schützt sie aber nicht automatisch. Die eigentliche Aufgabe ist, präzise Informationen über alle Komponenten bereitzustellen - für Abgleich mit Schwachstellendatenbanken, Risikoanalysen und Updates.

SBOM ist keine Schwachstellenlösung

Findet sich im SBOM eine Bibliothek mit bekannter Schwachstelle, bleibt es Aufgabe des Teams zu prüfen, wie kritisch das Problem ist, ob ein Update verfügbar und kompatibel ist und den Fix auszurollen. SBOM ist daher eher eine detaillierte Karte als eine automatische Schutzmaßnahme.

Nicht jede Schwachstelle ist für jede Anwendung gleich gefährlich. Oft genügt das Vorhandensein einer Komponente, um ein Risiko darzustellen - manchmal aber auch nicht. Deshalb sollte die Übereinstimmung von SBOM und Schwachstellendaten als Ausgangspunkt für die Prüfung dienen, nicht als finale Diagnose.

Risiken durch veraltete oder unvollständige SBOMs

Die Qualität der Daten ist entscheidend: Fehlen transitive Abhängigkeiten oder werden veraltete SBOMs genutzt, kann die Sicherheitsbewertung fehlerhaft sein. Auch schwer identifizierbare Komponenten - etwa abgewandelte interne Pakete - erschweren die automatische Analyse.

Deshalb sollte die SBOM-Erstellung eng an den Build- oder Release-Prozess gekoppelt sein und so wenig manuelle Eingriffe wie möglich erfordern.

SBOM als Teil der Software-Lieferkettensicherheit

Moderne Software ist abhängig von Paketmanagern, externen Bibliotheken, Containern, Buildsystemen und mehr - sie alle bilden die Software-Lieferkette. Wird einer dieser Bausteine kompromittiert, sind viele Produkte gleichzeitig betroffen.

Deshalb ist Lieferkettensicherheit ein zentraler Teil moderner Cybersecurity-Strategien. SBOM hilft, alle Komponenten und deren Einsatzorte zu erfassen - aber ergänzende Maßnahmen sind nötig: Schwachstellenscans, Herkunftskontrolle, Signaturprüfung, Updates und laufende Analysen.

Gerade nachträgliche Änderungen müssen überwacht werden. Werden aktuelle SBOMs gepflegt, lassen sich betroffene Versionen bei neuen Schwachstellen schnell finden. Ohne SBOM wird die Suche zum aufwändigen Ermittlungsprozess. Mit SBOM kann das Suchfeld erheblich eingegrenzt werden - und damit die Reaktionszeit im Ernstfall.

FAQ

1. Was ist ein SBOM einfach erklärt?
   Ein SBOM ist eine strukturierte Liste aller Bausteine einer Software - inklusive Bibliotheken, Paketen, ihren Versionen und Abhängigkeiten. Sie hilft, den tatsächlichen Aufbau einer Anwendung zu verstehen und potenziell gefährliche Komponenten schneller zu finden.
2. Warum braucht auch eine kleine Software ein SBOM?
   Selbst kleine Programme nutzen oft viele Fremdbibliotheken. Wird in einer davon eine Schwachstelle entdeckt, ermöglicht SBOM die zügige Überprüfung, ob und in welcher Version sie im eigenen Produkt steckt. Besonders bei weiterhin gepflegten Projekten ist SBOM unverzichtbar, da auch in alten Abhängigkeiten regelmäßig neue Schwachstellen auftauchen.
3. Kann SBOM Schwachstellen automatisch finden?
   SBOM selbst sucht keine Schwachstellen. Es liefert die Datenbasis über den Softwareaufbau. Für die Suche werden spezielle Scanner und Schwachstellendatenbanken verwendet, die die SBOM-Daten mit bekannten Bedrohungen abgleichen. Entwickler bewerten dann, wie kritisch die Funde sind und ob Updates oder andere Maßnahmen nötig werden.
4. Worin unterscheiden sich CycloneDX und SPDX?
   CycloneDX und SPDX sind die beiden wichtigsten SBOM-Standards. CycloneDX ist besonders für die Lieferkettensicherheit optimiert; SPDX wurde ursprünglich für Lizenz- und Herkunftsinformationen entwickelt, eignet sich aber ebenfalls für SBOM. Für die meisten Projekte zählt weniger das Format, sondern die Vollständigkeit und Aktualität der Daten.

Fazit

Ein SBOM ist wie die Zutatenliste eines Softwareprodukts: Es zeigt, aus welchen Bibliotheken, Paketen und weiteren Komponenten eine Anwendung besteht, welche Versionen genutzt werden und wie die Abhängigkeiten verknüpft sind.

Der größte Nutzen entsteht beim Umgang mit neuen Schwachstellen: Statt jedes Projekt einzeln zu prüfen, kann das Unternehmen mit SBOM gezielt nach betroffenen Komponenten suchen - das ist gerade bei modernen, komplexen Anwendungen mit vielen Fremdquellen und transitiven Abhängigkeiten entscheidend.

SBOM ist jedoch kein Ersatz für ganzheitliche Cybersicherheit. Es behebt keine Schwachstellen und garantiert keine Sicherheit, sondern schafft Transparenz: Entwickler erhalten eine präzise Übersicht, die sich automatisiert mit den neuesten Bedrohungsinformationen abgleichen lässt.

Damit dieser Ansatz funktioniert, muss für jede relevante Produktversion ein aktueller SBOM gepflegt werden - idealerweise automatisch und im Zusammenspiel mit regelmäßigen Sicherheits- und Komponentenupdates. Das vereinfacht die Kontrolle der Software-Lieferkette erheblich.