Was ist eine SBOM? Bedeutung, Formate, Beispiel und Werkzeuge

Eine SBOM (Software Bill of Materials, auf Deutsch Software-Stückliste) ist die Liste von allem, woraus eine Software besteht: jede Bibliothek, jedes Framework, jede Laufzeitumgebung und jedes Paket, mit genauer Version, Lieferant und Beziehung zum Rest. Stellen Sie sie sich als Zutatenliste eines Produkts vor, in einem Format, das eine Maschine lesen kann.

Die Idee stammt aus der Fertigung, wo eine Stückliste jedes Teil eines physischen Produkts aufführt. Software wird genauso zusammengesetzt: Eine typische Anwendung besteht heute größtenteils aus Open-Source-Komponenten, oft Hunderten, wenn man die Abhängigkeiten der Abhängigkeiten mitzählt.

Warum sie wichtig ist

Wird eine schwere Schwachstelle in einer weit verbreiteten Bibliothek veröffentlicht, bekommt jeder Softwarehersteller zuerst dieselbe Frage: Sind wir betroffen? Ohne SBOM heißt die Antwort, Repositories, Build-Dateien und Container-Images von Hand zu durchsuchen, für jedes Produkt und jede noch genutzte Version. Mit SBOM ist es eine Abfrage.

Deshalb ist die SBOM von der guten Praxis zur Pflicht geworden:

• In der Europäischen Union verlangt der Cyber Resilience Act von Herstellern eine SBOM für jedes Produkt mit digitalen Elementen; siehe was der CRA von einer SBOM verlangt.
• In den USA können Bundesbehörden in ihren Softwareverträgen eine verlangen, eine Praxis, die 2021 mit der Executive Order 14028 begann und seit Januar 2026 jeder Behörde selbst überlassen ist.
• Große Kunden verlangen sie zunehmend in ihren Einkaufsbedingungen, unabhängig davon, was das Gesetz sagt.

Was eine SBOM enthält

Für jede Komponente nennt eine brauchbare SBOM:

Feld	Beispiel
Name	express
Version	4.19.2
Lieferant	der Herausgeber der Komponente
Eine eindeutige Kennung	eine Package URL (purl) wie pkg:npm/express@4.19.2
Ein Hashwert	ein SHA-256 oder SHA-512 der ausgelieferten Datei
Lizenz	MIT
Beziehung	eine direkte Abhängigkeit des Produkts oder von einer anderen Komponente mitgebracht

Und für die SBOM als Ganzes: welches Produkt und welche Version sie beschreibt, wer sie erstellt hat, wann und mit welchem Werkzeug.

Diese Felder folgen den Mindestelementen, die die US-Behörde NTIA 2021 erstmals veröffentlichte (Lieferant, Name, Version, eindeutige Kennung, Abhängigkeitsbeziehung, Autor der SBOM, Zeitstempel). Die CISA ersetzte sie 2026 durch eine aktualisierte Liste, die unter anderem den Hashwert der Komponente, die Lizenz, den Namen des erzeugenden Werkzeugs und den Kontext der Erzeugung ergänzt. Das BSI geht in seiner Technischen Richtlinie TR-03183-2, die mit Blick auf den CRA geschrieben wurde, noch weiter.

Die Package URL verdient eine Erwähnung: Sie ist die Kennung, mit der ein Werkzeug eine Komponente ohne Raten mit Schwachstellendatenbanken abgleichen kann. Eine SBOM, die nur „openssl 3.0“ sagt, lässt Raum für Fehler; pkg:deb/debian/openssl@3.0.11-1~deb12u2 nicht.

Die zwei Formate: CycloneDX und SPDX

Zwei offene Standards dominieren, und jedes ernsthafte Werkzeug liest beide.

CycloneDX entstand 2017 bei OWASP, mit Blick auf Sicherheit. Es ist heute ein Standard von Ecma International, ECMA-424; seine aktuelle Version 1.7 ist die zweite Ausgabe dieses Standards. Es transportiert Informationen zu Schwachstellen und Ausnutzbarkeit (VEX) und deckt auch Dienste, Hardware, Modelle für maschinelles Lernen und Kryptografie ab.

SPDX stammt von der Linux Foundation und begann mit der Einhaltung von Open-Source-Lizenzen. Version 2.2.1 ist ein ISO-Standard, ISO/IEC 5962:2021; die aktuelle Version ist 3.0.1, die Profile für Sicherheit, KI und Datensätze ergänzt hat.

Welches wählen? Ohne Vorgabe ist CycloneDX für Sicherheitsarbeit die häufigere Wahl; SPDX nutzen Rechtsabteilungen oft bereits für Lizenzen. Beide werden in JSON (die übliche Wahl) oder XML serialisiert, und eine Umwandlung ist möglich, mit etwas Detailverlust. Das BSI akzeptiert CycloneDX ab 1.6 und SPDX ab 3.0.1.

Ein kurzes Beispiel

Hier eine minimale CycloneDX-SBOM in JSON für ein Produkt, das von einer Bibliothek abhängt:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "serialNumber": "urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79",
  "version": 1,
  "metadata": {
    "timestamp": "2026-11-08T09:00:00Z",
    "tools": { "components": [{ "type": "application", "name": "cdxgen" }] },
    "component": { "bom-ref": "gateway", "type": "application", "name": "Gateway", "version": "4.2.0",
      "supplier": { "name": "Acme Devices" } }
  },
  "components": [
    { "bom-ref": "express", "type": "library", "name": "express", "version": "4.19.2",
      "purl": "pkg:npm/express@4.19.2", "licenses": [{ "license": { "id": "MIT" } }] }
  ],
  "dependencies": [{ "ref": "gateway", "dependsOn": ["express"] }]
}

Der Block metadata beschreibt das Produkt und wie die SBOM erstellt wurde; components listet auf, was enthalten ist; dependencies sagt, wie die Teile zusammenhängen. Eine echte SBOM hat dieselbe Form, mit Hunderten Komponenten. Sie können Ihre eigene in unserem kostenlosen SBOM-Viewer und -Prüfer öffnen, der auch die fehlenden Felder auflistet.

Arten von SBOMs

Dasselbe Produkt lässt sich zu verschiedenen Zeitpunkten beschreiben, und die Ergebnisse unterscheiden sich. Die CISA nennt sechs Typen:

• Design: was Sie verwenden wollen, bevor es Code gibt.
• Source: aus dem Quellcode und seinen Manifesten gelesen.
• Build: während des Builds der Version erzeugt, aus dem, was der Build tatsächlich geholt hat. Für Software meist die genaueste.
• Analysed: nachträglich durch Scannen einer Binärdatei oder eines Images rekonstruiert.
• Deployed: was auf einem bestimmten System installiert ist.
• Runtime: was während der Ausführung tatsächlich geladen wird.

Für einen Hersteller zählt eine Build-SBOM für jede Version: Sie beschreibt, was Sie ausliefern.

Wie Sie eine erzeugen

Schreiben Sie eine SBOM nicht von Hand. Erzeugen Sie sie in Ihrer Build-Pipeline, bei jeder Version, aus Ihren Lock-Dateien und den Images, die Sie ausliefern. Verbreitete Open-Source-Generatoren sind:

• Syft (Anchore): Container-Images und Dateisysteme, viele Ökosysteme.
• cdxgen (OWASP CycloneDX): Quell-Repositories in vielen Sprachen.
• Trivy (Aqua Security): Images, Dateisysteme und Repositories, mit eingebautem Schwachstellenscan.
• Die CycloneDX-Plugins für Maven, Gradle, npm, .NET, Python und andere, die aus dem Build heraus arbeiten.
• Das sbom-tool von Microsoft, für SPDX.
• Zum Ausprobieren ohne Installation: Unser kostenloser SBOM-Generator macht aus Lock-Dateien CycloneDX oder SPDX in Ihrem Browser, mit provetry-core, der Open-Source-Engine hinter Provetry.

Prüfen Sie im Ergebnis, egal mit welchem Werkzeug, drei Dinge: Jede Komponente hat eine Version und eine Package URL, transitive Abhängigkeiten sind aufgeführt und nicht nur direkte, und die SBOM nennt das Produkt und die Version, zu der sie gehört.

Die Befehle und Stolperfallen jedes Ökosystems haben einen eigenen Leitfaden: npm, pnpm und Yarn, Python, Java, Rust, Go, .NET und Container-Images.

Eine SBOM ist ein Ausgangspunkt

Eine SBOM allein bewirkt nichts. Ihr Wert entsteht durch das, was Sie damit tun:

1. Bewahren Sie eine pro Version auf, damit Sie sagen können, welche Versionen im Feld eine Komponente enthalten.
2. Gleichen Sie sie täglich mit Schwachstellendaten ab: Neue Schwachstellen werden zu Komponenten veröffentlicht, die Sie vor Monaten ausgeliefert haben. Priorisieren Sie mit dem EPSS-Score und den Listen ausgenutzter Schwachstellen.
3. Halten Sie Ihre Schlussfolgerungen fest, wenn eine verwundbare Komponente vorhanden ist, in Ihrem Produkt aber nicht ausgenutzt werden kann; dafür ist eine VEX-Aussage da.
4. Teilen Sie sie auf Anfrage, mit Kunden oder Behörden. Nichts verpflichtet Sie, sie zu veröffentlichen.

Wie Provetry hilft

Provetry erstellt die SBOM jeder Version aus Ihrer CI oder aus den Dateien, die Sie hochladen, in CycloneDX und SPDX, bewahrt die SBOM jeder Version auf, gleicht jede Komponente täglich mit neuen und ausgenutzten Schwachstellen ab und hält Ihre VEX-Entscheidungen fest. Der kostenlose Tarif umfasst ein Produkt.

Quellen

• CycloneDX-Spezifikation und ECMA-424
• SPDX-Spezifikationen
• NTIA: The Minimum Elements for a Software Bill of Materials (2021)
• CISA: Software Bill of Materials, mit den Mindestelementen und den SBOM-Typen
• BSI: Technische Richtlinie TR-03183 (englische Fassung)
• Package-URL-Spezifikation