Software Bill of Materials (SBOM)

Eine Software Bill of Materials (SBOM) ist ein maschinenlesbares, formal strukturiertes Verzeichnis aller Komponenten, Bibliotheken und Abhängigkeiten, aus denen ein Softwareprodukt besteht — einschließlich ihrer Versionen, Herkunft und Abhängigkeitsbeziehungen untereinander.

Die Analogie zur Stückliste aus der Fertigung ist beabsichtigt und trägt weit. Ein Automobilhersteller weiß, welcher Zulieferer welches Bauteil in welcher Charge geliefert hat, und kann bei einem Materialfehler gezielt zurückrufen. Für Software galt dieser Selbstverständlichkeit lange nicht. Eine typische Webanwendung enthält heute mehr fremden als eigenen Code, verteilt über hunderte direkte und transitive Abhängigkeiten. Ohne Inventar bleibt die Frage, welche Fremdbestandteile ein Produkt enthält, unbeantwortbar.

Was eine SBOM enthält

Die US-amerikanische National Telecommunications and Information Administration (NTIA) hat 2021 die sogenannten Minimum Elements definiert, die bis heute die verbreitetste Referenz für den Mindestinhalt darstellen. Sie gliedern sich in drei Blöcke: die Datenfelder je Komponente, die Anforderungen an Automatisierbarkeit und die Prozessvorgaben.

Als Basisdatenfelder je Komponente nennt das Dokument:

• Supplier Name — der Name der Organisation oder Person, die die Komponente bereitstellt.
• Component Name — die Bezeichnung der Komponente selbst.
• Version of the Component — die genaue Version, ohne die jede Schwachstellenzuordnung wertlos ist.
• Other Unique Identifiers — eindeutige Kennungen wie Package URL (purl) oder CPE, die maschinelle Zuordnung überhaupt erst ermöglichen.
• Dependency Relationship — die Beziehung zwischen den Komponenten, also welches Element welches enthält.
• Author of SBOM Data — wer das Dokument erstellt hat.
• Timestamp — wann es erstellt wurde.

Hinzu kommen die Anforderungen an die Automatisierung — die SBOM muss in einem maschinenlesbaren Standardformat vorliegen und automatisiert erzeugt und verarbeitet werden können — sowie Prozessanforderungen, etwa dass für jede neue Softwareversion eine neue SBOM entsteht und definiert ist, wie tief die Abhängigkeitskette abgebildet wird.

Im Juli 2026 haben die US-Behörde CISA und eine Reihe internationaler Partnerbehörden eine überarbeitete Fassung dieser Mindestelemente veröffentlicht — die erste vollständige Aktualisierung des 2021 gesetzten Ausgangspunkts. Die Erweiterungen zielen unter anderem auf zusätzliche Felder wie kryptografische Prüfsummen und Lizenzangaben.

Die etablierten Formate

Zwei Formate haben sich international durchgesetzt. Beide sind offen, maschinenlesbar und werden von Regulierungsseite akzeptiert.

Die funktionalen Unterschiede sind über die Jahre geschrumpft. Beide Formate bilden denselben Kernbestand ab und tragen purl- sowie CPE-Kennungen. Was sie heute noch unterscheidet, sind Schwerpunkt, Governance-Herkunft und die jeweils umgebende Werkzeuglandschaft. Für die Formatwahl in einem konkreten Projekt sind daher meist pragmatische Kriterien ausschlaggebend: Welches Format erwarten die eigenen Kunden, und welches unterstützt die eingesetzte Werkzeugkette besser? Eine Umwandlung zwischen beiden ist möglich, aber nicht immer verlustfrei.

Ein verbreiteter Irrtum ist übrigens die Annahme, ISO/IEC 5962:2021 beschreibe die aktuelle SPDX-Fassung. Die Norm bildet SPDX 2.2.1 ab; wer in einem Vertrag auf sie verweist, benennt damit diese Version, nicht die 3er-Reihe.

Regulatorischer Kontext

Der Aufstieg der SBOM vom Nischenthema zur Anforderung verlief in wenigen Jahren und wurde maßgeblich durch Regulierung getrieben.

Executive Order 14028. Die im Mai 2021 erlassene US-Präsidialverordnung „Improving the Nation's Cybersecurity" verpflichtete Lieferanten von Software an US-Bundesbehörden, eine SBOM bereitzustellen. Sie ist der Auslöser für die NTIA Minimum Elements und hat den Begriff über die Sicherheitscommunity hinaus bekannt gemacht. Das NIST hat die begleitende Arbeit zu Software-Lieferketten dokumentiert.

EU Cyber Resilience Act (CRA). Die europäische Verordnung über horizontale Cybersicherheitsanforderungen für Produkte mit digitalen Elementen trat am 10. Dezember 2024 in Kraft. Die Pflichten greifen gestaffelt: Kapitel IV zur Notifizierung von Konformitätsbewertungsstellen gilt ab dem 11. Juni 2026, die Meldepflichten für aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle ab dem 11. September 2026, die übrigen Hauptpflichten ab dem 11. Dezember 2027. Der CRA verlangt von Herstellern, eine Stückliste der Softwarekomponenten in einem gängigen, maschinenlesbaren Format zu führen. SPDX und CycloneDX erfüllen diese Formatanforderung beide.

NIS-2 und nationale Vorgaben. Ergänzend adressiert die NIS-2-Richtlinie die Sicherheit von Lieferketten aus Betreiberperspektive. In Deutschland konkretisiert die technische Richtlinie TR-03183 des Bundesamts für Sicherheit in der Informationstechnik die Anforderungen an SBOMs und geht dabei in Teilen über den Mindeststandard hinaus.

Für mittelständische Hersteller ist die Konsequenz greifbar: Wer Produkte mit digitalen Elementen in der EU in Verkehr bringt, wird eine Komponentenstückliste vorhalten müssen. Für Dienstleister und Agenturen wiederum verschiebt sich die Erwartung — Kunden werden die SBOM zunehmend als Bestandteil der Lieferung erwarten, nicht als kostenpflichtige Zusatzleistung.

Erzeugung im Build-Prozess

Eine SBOM, die von Hand gepflegt wird, ist am Tag ihrer Fertigstellung veraltet. Der praktikable Weg ist die automatische Erzeugung als Schritt der Build-Pipeline, sodass mit jedem Artefakt die passende Stückliste entsteht.

• Syft (von Anchore) analysiert Container-Images, Dateisysteme und Verzeichnisse und erzeugt SBOMs in beiden gängigen Formaten. Besonders verbreitet in containerbasierten Umgebungen.
• cdxgen erzeugt CycloneDX-SBOMs für eine große Bandbreite an Programmiersprachen und Paketmanagern und deckt damit polyglotte Projekte ab.
• Ergänzend existieren Sprach- und Ökosystem-spezifische Werkzeuge sowie Funktionen direkt in Build-Werkzeugen und Container-Registries.

Entscheidend ist der Zeitpunkt: Eine SBOM, die aus dem gebauten Artefakt erzeugt wird, bildet ab, was tatsächlich ausgeliefert wird. Eine SBOM, die allein aus Manifest-Dateien im Quellcode abgeleitet wird, bildet die Absicht ab. Beides hat seinen Platz, aber nur Ersteres ist im Ernstfall belastbar. Ebenso wichtig ist die Aufbewahrung: Die SBOM muss der ausgelieferten Version zugeordnet und über deren gesamten Lebenszyklus auffindbar bleiben, sonst fehlt sie genau dann, wenn sie gebraucht wird.

Realbeispiel: Log4Shell

Der praktische Nutzen wurde im Dezember 2021 schlagartig sichtbar. Mit CVE-2021-44228 wurde eine kritische Schwachstelle in der Java-Protokollierungsbibliothek Apache Log4j veröffentlicht, die unter dem Namen Log4Shell bekannt wurde. Die Bibliothek ist extrem weit verbreitet und geriet in zahllose Anwendungen als transitive Abhängigkeit — eingebunden nicht direkt, sondern über andere Komponenten, die ihrerseits Log4j nutzten.

Die drängendste Frage in den Tagen danach war weder, wie gefährlich die Lücke ist, noch wie man sie schließt. Beides war schnell geklärt. Die Frage war: Wo steckt die Bibliothek überhaupt? Organisationen mit vollständiger, versionsgenauer Komponenteninventur konnten sie durch eine Abfrage beantworten. Alle anderen suchten manuell durch Anwendungen, Container-Images und Archive — teils über Wochen, teils mit dem unbefriedigenden Ergebnis, es nicht sicher zu wissen. Genau diese Differenz ist der Geschäftswert einer SBOM.

Nutzen jenseits der Sicherheit

Die Schwachstellenbehandlung ist der prominenteste, aber nicht der einzige Anwendungsfall.

• Lizenz-Compliance: Welche Open-Source-Lizenzen sind im Produkt enthalten, und vertragen sie sich mit dem eigenen Vertriebsmodell? Copyleft-Lizenzen in einem proprietären Produkt sind ein wirtschaftliches Risiko, das ohne Inventar unentdeckt bleibt.
• Einkauf und Lieferantenbewertung: Eine SBOM macht vergleichbar, wie aktuell und wie verwaltet der Komponentenbestand eines zugekauften Produkts ist.
• Technische Bewertung bei Übernahmen: Bei Due-Diligence-Prüfungen ersetzt eine belastbare Stückliste aufwendige manuelle Analysen.
• Interne Standardisierung: Über mehrere Produkte hinweg zeigt der Vergleich, wo dieselbe Aufgabe mit fünf verschiedenen Bibliotheken gelöst wird.

Grenzen und Missverständnisse

Eine SBOM ist ein Inventar, keine Sicherheitsbewertung. Sie sagt aus, was enthalten ist — nicht, ob es sicher ist. Die Bewertung entsteht erst durch den Abgleich mit Schwachstellendatenbanken, und dieser Abgleich braucht aktuelle Daten und einen Prozess, der auf Treffer reagiert. Eine SBOM, die niemand auswertet, erzeugt Aufwand ohne Nutzen.

Zweitens ist nicht jeder Treffer relevant. Eine verwundbare Bibliothek im Produkt bedeutet nicht zwingend, dass das Produkt angreifbar ist — der betroffene Codepfad wird möglicherweise nie ausgeführt. Für diese Unterscheidung existiert das ergänzende Konzept VEX (Vulnerability Exploitability eXchange), mit dem Hersteller dokumentieren, ob eine bekannte Schwachstelle im konkreten Produkt tatsächlich ausnutzbar ist. Ohne diese Ergänzung ertrinken Teams in Befunden, die keine sind.

Drittens ist die Vollständigkeit begrenzt. Statisch eingebundener Code, mitgelieferte Binärdateien ohne Paketmetadaten und im Betrieb nachgeladene Bestandteile entziehen sich der automatischen Erfassung häufig. Eine SBOM ist eine sehr gute Näherung, kein lückenloser Beweis.

Viertens ist die Verbreitung selbst ein offenes Thema: Formate, Aufbewahrung und der Austausch zwischen Hersteller und Kunde sind technisch gelöst, organisatorisch aber in vielen Lieferbeziehungen noch nicht etabliert.

Ausblick

Die Richtung ist absehbar. Mit dem Wirksamwerden der CRA-Hauptpflichten Ende 2027 wird die Komponentenstückliste für einen großen Teil der in der EU vertriebenen Produkte mit digitalen Elementen zur Voraussetzung für den Marktzugang. Parallel arbeiten die Standardisierungsgremien und Initiativen wie die OpenSSF an einer engeren Abstimmung zwischen den Formaten und den regulatorischen Anforderungen, damit ein Dokument mehrere Rechtsräume bedienen kann.

Inhaltlich zeichnet sich eine Ausweitung des Konzepts ab: Neben der klassischen Software-Stückliste entstehen verwandte Stücklisten für Hardware, für die in einem Produkt verwendeten kryptografischen Verfahren und für die Bestandteile von KI-Systemen. Der gemeinsame Nenner bleibt derselbe — nachvollziehbar zu machen, woraus ein Produkt besteht.

Häufige Fragen

Wer braucht eine SBOM?

Jede Organisation, die Software herstellt oder vertreibt, sowie zunehmend auch Betreiber, die Auskunft über eingesetzte Komponenten geben müssen. Mit dem Cyber Resilience Act wird die Stückliste für Produkte mit digitalen Elementen in der EU zur Pflicht.

SPDX oder CycloneDX — welches Format?

Beide sind normiert und regulatorisch akzeptiert. In der Praxis entscheiden Kundenanforderung und Werkzeugunterstützung. Konvertierung ist möglich, aber nicht immer verlustfrei.

Wie oft muss eine SBOM erneuert werden?

Mit jeder Version der Software. Da sich Abhängigkeiten mit jedem Build ändern können, ist die automatische Erzeugung in der Pipeline der einzige praktikable Weg.

Ersetzt eine SBOM einen Schwachstellen-Scan?

Nein. Die SBOM ist die Datengrundlage, der Abgleich mit Schwachstellendatenbanken die Auswertung. Beides gehört zusammen, ergänzt um eine Aussage zur tatsächlichen Ausnutzbarkeit über VEX.

Muss eine SBOM veröffentlicht werden?

Nicht zwingend. Sie kann vertraulich an Kunden, Prüfstellen oder Behörden übergeben werden. Die Regulierung verlangt Verfügbarkeit gegenüber bestimmten Adressaten, keine allgemeine Offenlegung.

Die Spezifikation und die Werkzeuglandschaft des CycloneDX-Formats sind dokumentiert unter cyclonedx.org.