Was ist eine SBOM?
Eine Software Bill of Materials, kurz SBOM, ist eine maschinenlesbare Liste aller Komponenten, Bibliotheken und Abhängigkeiten, aus denen eine Software zusammengesetzt ist. Sie lässt sich am ehesten mit einer Zutatenliste vergleichen, wie man sie von Lebensmitteln kennt, übertragen auf den Aufbau eines Programms. Hintergrund ist die Erkenntnis, dass moderne Anwendungen zu großen Teilen aus fremdem Code bestehen, der über Paketmanager eingebunden wird. Wer nicht weiß, was genau in einem Release steckt, kann weder Sicherheitslücken zuverlässig schließen noch Lizenzpflichten verlässlich erfüllen.
Warum SBOMs heute wichtig sind
Eine SBOM schafft an mehreren Stellen Klarheit. Sie macht transparent, welche Komponenten in welcher Version tatsächlich ausgeliefert werden. Sie ist die Grundlage, um beim Bekanntwerden einer Schwachstelle schnell zu erkennen, welche Systeme betroffen sind, ohne jedes Projekt manuell durchsuchen zu müssen. Sie hilft, lizenzrechtliche Anforderungen zu überblicken, gerade in Projekten, die Open-Source-Komponenten mit unterschiedlichen Lizenzen kombinieren. Und sie wird zunehmend zur Pflicht: Mit dem Cyber Resilience Act der EU werden SBOMs ab dem Geltungsbeginn ein fester Bestandteil der Anforderungen an Produkte mit CE-Kennzeichnung im digitalen Bereich.
Formate im Überblick
Drei Standards prägen den Markt. SPDX wurde von der Linux Foundation entwickelt, ist als ISO/IEC 5962:2021 normiert und legt einen Schwerpunkt auf Lizenz-Compliance. CycloneDX entstand im Umfeld der OWASP-Community und stellt Sicherheitsthemen in den Mittelpunkt, einschließlich Erweiterungen für die Bewertung und Offenlegung von Schwachstellen, etwa über das VEX-Konzept. SWID Tags nach ISO/IEC 19770-2 dienen schließlich der eindeutigen Softwareidentifikation, häufig im Kontext von Asset Management.
Inhalte einer SBOM
Eine vollständige SBOM enthält für jede Komponente Angaben zu Name und Version, zum Lieferanten oder Hersteller, zu Lizenzen und zu den weiterführenden Abhängigkeiten dieser Komponente. Über kryptografische Hashes lässt sich die Identität einer Komponente zweifelsfrei prüfen, sodass auch nachträglich erkennbar bleibt, ob die ausgelieferte Datei tatsächlich der gelisteten Variante entspricht. Optional können bekannte Schwachstellen ergänzt werden, was die SBOM zu einem aktiven Sicherheitsdokument macht.
Erzeugung im Entwicklungsalltag
In der Praxis entstehen SBOMs entweder direkt aus den Paketmanagern oder über spezialisierte Werkzeuge. Viele moderne Paketmanager bringen inzwischen eigene Befehle mit, die eine SBOM im CycloneDX-Format ausgeben; im Composer-Umfeld leistet beispielsweise composer audit ähnliche Dienste für die Sicht auf Schwachstellen. Darüber hinaus haben sich dedizierte Werkzeuge etabliert: Syft erzeugt SBOMs für eine breite Palette an Ökosystemen, Trivy kombiniert die Erstellung mit einem Security-Scanner, und Grype prüft fertige SBOMs gegen bekannte Schwachstellen. Im CI/CD-Umfeld wird der Schritt typischerweise als eigene Pipeline-Stage automatisiert, sodass mit jedem Build eine aktuelle SBOM entsteht und gemeinsam mit dem Artefakt archiviert wird.
Empfehlungen für die Praxis
Damit eine SBOM mehr ist als ein einmal erzeugtes Dokument, haben sich einige Grundsätze bewährt:
- SBOMs automatisiert im Release-Prozess erzeugen und gemeinsam mit dem zugehörigen Artefakt versionieren
- Automatisierte Schwachstellen-Checks gegen aktuelle Datenbanken einplanen und Befunde priorisieren
- Lizenzangaben regelmäßig auf Konflikte mit dem eigenen Lizenzmodell prüfen, gerade bei Anwendungen, die an Kunden ausgeliefert werden
So wird die SBOM zu einem lebendigen Bestandteil der Lieferkette und nicht nur zu einer Pflichtübung.
Bedeutung für die Praxis
Für Web-Projekte mit vielen Abhängigkeiten, sei es im JavaScript-, PHP- oder Python-Umfeld, schafft eine SBOM Übersicht und Reaktionsfähigkeit. Wenn die nächste größere Schwachstelle in einer weit verbreiteten Bibliothek bekannt wird, entscheidet eine aktuelle SBOM darüber, ob Stunden oder Tage vergehen, bis betroffene Systeme identifiziert sind. Sie ist damit kein Selbstzweck, sondern eine zentrale Grundlage moderner Softwarepflege.