Eine Software Bill of Materials, kurz SBOM, ist die Zutatenliste moderner Software. Sie zeigt, welche Komponenten, Bibliotheken und Abhängigkeiten in einem Produkt stecken. Genau diese Transparenz wird wichtiger, weil Sicherheitslücken heute selten nur eine einzelne Anwendung betreffen, sondern ganze Lieferketten.
Warum ist das Thema relevant?
Software entsteht heute fast nie komplett aus eigener Hand. Anwendungen bestehen aus Open-Source-Bibliotheken, Frameworks, Containern, Build-Werkzeugen, kommerziellen Komponenten und Code, der von Zulieferern stammt. Das ist effizient, aber es schafft eine unangenehme Frage: Wer weiß im Ernstfall wirklich, was in welcher Version wo verbaut ist?
Die Log4j-Schwachstelle hat diese Frage vielen Organisationen schmerzhaft vor Augen geführt. Nicht die Existenz einer Schwachstelle war das größte organisatorische Problem, sondern die Suche: Welche Produkte enthalten die betroffene Bibliothek? Welche Version? Direkt oder nur als transitive Abhängigkeit? Bei welchen Systemen ist die Schwachstelle tatsächlich ausnutzbar? Ohne belastbares Inventar wird aus Vulnerability Management schnell Detektivarbeit.
CISA beschreibt SBOMs deshalb als Baustein für Software-Sicherheit und Lieferkettenrisikomanagement. Die Idee ist nüchtern: Betreiber, Hersteller und Beschaffungsteams sollen nicht erst in der Krise herausfinden müssen, woraus eine Software besteht.
Was ist eine Software Bill of Materials?
Eine SBOM ist ein strukturiertes, maschinenlesbares Inventar der Softwarebestandteile eines Produkts. Der oft genutzte Vergleich mit einer Zutatenliste trifft den Kern, greift aber etwas zu kurz. Software hat nicht nur Zutaten, sondern Versionen, Abhängigkeitsbeziehungen, Lizenzen, Build-Kontexte und laufende Updates.
Typische Einträge beschreiben den Namen einer Komponente, Version, Hersteller oder Projekt, eindeutige Identifikatoren, Hashes, Lizenzinformationen und Beziehungen zu anderen Komponenten. Wichtig sind auch transitive Abhängigkeiten: Eine Anwendung nutzt Bibliothek A, Bibliothek A nutzt wiederum Bibliothek B. Für die Sicherheit kann Bibliothek B entscheidend sein, obwohl sie im Produktmarketing nie auftaucht.
Eine gute SBOM ist deshalb kein PDF-Anhang für den Einkauf, sondern ein Datenartefakt, das Werkzeuge auslesen und mit Schwachstelleninformationen, Asset-Daten und Risikokontext verbinden können.
Wie funktioniert eine SBOM praktisch?
SBOMs können an verschiedenen Stellen entstehen: während der Entwicklung, in der Build-Pipeline, beim Release, durch Analyse fertiger Container-Images oder durch Software Composition Analysis. Am zuverlässigsten sind sie, wenn sie nah am tatsächlichen Build-Prozess erzeugt werden. Dann ist die Chance höher, dass die Liste wirklich zum ausgelieferten Artefakt passt.
In der Praxis haben sich Formate wie SPDX und CycloneDX etabliert. SPDX kommt stark aus dem Lizenz- und Komponentenmanagement, CycloneDX ist im Security-Kontext verbreitet. Beide verfolgen dasselbe Grundziel: Softwarebestandteile so zu beschreiben, dass Maschinen sie verarbeiten können. Entscheidend ist weniger die Formatdebatte als die Anschlussfähigkeit an Prozesse: Kann das Security-Team die SBOM importieren? Kann Beschaffung Mindestanforderungen prüfen? Kann der Betrieb bei einer neuen CVE schnell nachschlagen?
Eine SBOM muss außerdem aktualisiert werden. Software verändert sich durch Patches, neue Builds, Container-Rebuilds und Lieferantenupdates. Eine veraltete SBOM ist besser als gar keine, aber sie kann falsche Sicherheit erzeugen.
Warum ist eine SBOM wichtig?
Der offensichtlichste Nutzen liegt im Schwachstellenmanagement. Wenn eine kritische CVE veröffentlicht wird, kann eine Organisation ihre SBOM-Daten gegen Vulnerability-Datenbanken prüfen. Statt manuell jedes Produkt und jeden Anbieter abzufragen, lässt sich schneller eingrenzen, wo Handlungsbedarf besteht.
Der zweite Nutzen betrifft Beschaffung und Lieferantensteuerung. Wer Software einkauft oder in Geräte integriert, kann SBOMs als Teil der Sicherheitsdokumentation verlangen. Das ersetzt keine Prüfung, schafft aber eine gemeinsame Sprache zwischen Hersteller, Integrator und Betreiber. Gerade bei langlebigen Systemen, industrieller Software, vernetzten Geräten oder kritischen Betriebsumgebungen ist diese Transparenz wertvoll.
Drittens helfen SBOMs bei Audits und Verantwortlichkeiten. Sie zeigen, welche Open-Source-Komponenten und Lizenzen eingesetzt werden, welche Abhängigkeiten gepflegt werden müssen und wo sich Risiken konzentrieren. In Europa wird das durch Regulierungsdebatten rund um Produktsicherheit, Cyber Resilience und Lieferketten zusätzlich relevant. Pauschal gesetzlich verpflichtend sind SBOMs nicht überall; Anforderungen hängen von Branche, Produkt, Beschaffung und Rechtsraum ab.
SBOM, VEX und Vulnerability Management
Eine SBOM beantwortet zuerst die Frage: Was steckt drin? Sie beantwortet nicht automatisch die Frage: Ist dieses Produkt wegen einer konkreten Schwachstelle tatsächlich gefährdet? Genau hier kommt VEX ins Spiel, also Vulnerability Exploitability eXchange.
VEX-Daten können ergänzend beschreiben, ob eine bekannte Schwachstelle in einem konkreten Produkt betroffen, nicht betroffen, behoben oder noch in Untersuchung ist. Das ist wichtig, weil nicht jede verwundbare Bibliotheksversion in jeder Nutzung ausnutzbar ist. Manchmal ist ein anfälliger Codepfad nicht erreichbar, eine Funktion deaktiviert oder eine Komponente nur zur Build-Zeit relevant.
SBOM und VEX sind daher keine Konkurrenz. Die SBOM liefert Inventartransparenz, VEX liefert Kontext zur Ausnutzbarkeit. Wirksam wird beides erst mit Prozessen: Wer erzeugt die Daten? Wer aktualisiert sie? Wer bewertet Warnungen? Wer entscheidet über Patches, Kompensationsmaßnahmen oder Akzeptanz von Restrisiken?
Chancen, Grenzen und Risiken
Die größte Chance einer SBOM liegt in Geschwindigkeit. Organisationen können bei neuen Schwachstellen schneller reagieren, Lieferanten gezielter ansprechen und Risiken präziser priorisieren. Außerdem verbessert sie die Kommunikation: Statt vager Aussagen wie „wir prüfen das“ gibt es konkrete Komponenten, Versionen und Bezüge.
Die Grenzen sind ebenso wichtig. SBOMs können unvollständig sein, proprietäre Blackboxes ausblenden, transitive Abhängigkeiten falsch erfassen oder durch Tool-Unterschiede variieren. Bei SaaS- und Cloud-Diensten ist zusätzlich zu klären, welche Transparenz der Anbieter überhaupt liefert und wie häufig sich die zugrunde liegende Software ändert.
Ein weiteres Risiko ist die Scheinsicherheit. Eine SBOM beweist nicht, dass Software sicher entwickelt wurde. Sie ersetzt keine sichere Architektur, keine Code-Reviews, keine Tests, keine Signierung, keine Patch-Prozesse und kein Incident Response. Sie ist Infrastruktur für bessere Entscheidungen, nicht die Entscheidung selbst.
Was gehört zu einer guten SBOM-Strategie?
Erstens braucht es klare Mindestdaten: Komponentenname, Version, eindeutige Identifikatoren, Lieferant oder Projekt, Abhängigkeitsbeziehungen und Erstellungszeitpunkt. Zweitens sollte die SBOM automatisch erzeugt und versioniert werden. Manuell gepflegte Listen altern schnell und werden im Alltag selten zuverlässig aktualisiert.
Drittens muss die SBOM in bestehende Systeme passen: Asset Management, Vulnerability Scanner, Ticketing, CI/CD, Einkauf und Lieferantenmanagement. Der Wert entsteht nicht durch die Datei, sondern durch den Abgleich mit operativen Daten. Viertens sollten Organisationen festlegen, wie mit Funden umgegangen wird. Ein endloser Strom an CVE-Treffern ohne Priorisierung überfordert Teams und führt zu Alarmmüdigkeit.
Für Hersteller bedeutet das: SBOMs werden Teil professioneller Produktdokumentation. Für Betreiber bedeutet es: SBOMs sollten eingefordert, gespeichert und auswertbar gemacht werden. Für beide Seiten gilt: Transparenz ist nur nützlich, wenn sie aktuell, verständlich und handlungsfähig bleibt.
Für Teams heißt das praktisch: Eine SBOM sollte nicht irgendwo abgelegt und vergessen werden. Sie gehört in regelmäßige Release-Prozesse, in Lieferantenanforderungen und in die Sicherheitsabläufe nach der Veröffentlichung. Erst wenn neue Schwachstellen automatisch gegen bekannte Komponenten laufen und Verantwortliche daraus konkrete Maßnahmen ableiten, wird aus Transparenz ein belastbarer Sicherheitsvorteil.
Fazit
Eine Software Bill of Materials ist keine Wunderwaffe. Sie macht Software nicht automatisch sicher und sie verhindert keine Schwachstellen. Aber sie beantwortet eine Grundfrage, die in modernen IT-Landschaften zu oft unbeantwortet bleibt: Woraus besteht diese Software eigentlich?
Genau deshalb ist die SBOM ein wichtiger Baustein für Software-Lieferketten. Sie schafft Transparenz, beschleunigt Reaktionen auf Schwachstellen und macht Risiken verhandelbar. Wer Software entwickelt, einkauft oder betreibt, sollte diese Zutatenliste nicht als Bürokratie verstehen, sondern als Arbeitsgrundlage. Im Krisenfall ist sie der Unterschied zwischen gezielter Analyse und hektischer Suche.
Quellen und weiterführende Informationen
Der Artikel basiert auf öffentlich zugänglichen Fach- und Institutionsquellen. Wichtige Ausgangspunkte waren:
- CISA: Software Bill of Materials
- NTIA: Software Bill of Materials
- CISA: Framing Software Component Transparency 2024
- SPDX specification
- CycloneDX specification
Hinweis: Für diesen Artikel wurden KI-gestützte Recherche- und Editierwerkzeuge verwendet. Der Inhalt wurde menschlich redaktionell geprüft. Stand: 26.04.2026.
