Zum Inhalt springen
← Glossar
Glossar · Schwachstellen managen

SBOM - Software Bill of Materials

Software-Stückliste

Lesezeit: 5 Min.

Was bedeutet SBOM?

Eine SBOM ist eine maschinenlesbare Liste aller Komponenten und Bibliotheken, aus denen eine Software besteht.

Eine SBOM (Software Bill of Materials) ist eine vollständige, strukturierte Inventarliste aller technischen Komponenten, Abhängigkeiten und Versionen, aus denen ein Softwareprodukt besteht, analog zur Stückliste (BOM) in der Fertigungsindustrie. Sie dokumentiert nicht nur die direkten Libraries (z.B. „Apache Log4j 2.14.1"), sondern auch transitive Abhängigkeiten (Bibliotheken die andere Bibliotheken benötigen) mit ihren genauen Versionsnummern, Lizenzen und Herkunftsangaben. Formate wie SPDX und CycloneDX ermöglichen es, SBOMs maschinenlesbar bereitzustellen. Die SBOM ist das Fundament für schnelle Schwachstellenanalyse: Bei neuer Lücke (z.B. CVE-2021-44228 Log4Shell) können Scanner automatisch gegen die SBOM abgleichen und sofort sagen: „Sie nutzen Log4j 2.14.1 → Sie sind betroffen." Ohne SBOM: Manuelles Durchsuchen von Dokumentationen, Zeitverschwendung, Risiken werden übersehen.

Das Problem ohne SBOM: Das Log4Shell-Beispiel

Dezember 2021: Log4Shell (CVE-2021-44228) wird öffentlich, CVSS 10,0, aktive Exploits.

Unternehmen mussten in STUNDEN feststellen: „Nutzen wir Log4j? In welchen Versionen? Wo läuft es?" Ohne SBOM: Chaos. Entwickler mussten jede Applikation manuell durchsuchen, Build-Tools abfragen, Dokumentationen lesen. Tage vergingen.

Mit SBOM: Machine durchsucht die SBOM, sagt in 1 Minute: „Log4j 2.14.1 in Applikation X, Y, Z → Upgrade auf 2.16.0 erforderlich." Dieser Unterschied (Chaos vs. Minuten) ist der Kern, warum SBOM jetzt Pflicht ist.

SBOM-Pflicht im EU Cyber Resilience Act (CRA)

Der Cyber Resilience Act (EU 2024/2847, siehe offizielle Verordnung) verpflichtet ab 2025 Hersteller von Produkten mit digitalen Elementen zur Erstellung und Vorhaltung einer SBOM. Die Kernpflichten (basierend auf CRA Artikel 10):

  1. SBOM muss vor Marktplatzierung vorhanden sein, maschinenlesbar, und aktuell gehalten werden.
  2. Die BSI TR-03183-2 konkretisiert Anforderungen für den deutschen Markt.
  3. Auf Anfrage von Marktüberwachungsbehörden muss die SBOM bereitgestellt werden.
  4. Die SBOM ist Nachweisdokumentation für Sicherheitsmaßnahmen nach CRA. Nicht-Compliance kann zu Marktverbot, Geldstrafen oder Haftung für Schäden führen.

Für KMUs: Falls Sie Software/Hardware mit digitalen Elementen entwickeln und im EU-Markt verkaufen, ist SBOM jetzt verpflichtend, nicht optional.

SBOM-Formate: SPDX vs. CycloneDX

SPDX (Software Package Data Exchange): Entwickelt von der Linux Foundation, ISO/IEC 5962:2021 standardisiert.

Fokus: Lizenzen und Quellen dokumentieren, detailliert.

Formate: JSON, XML, RDF, YAML.

Nutzer: Lizenzcompliance-Teams, große Organisationen.

CycloneDX: Aus OWASP-Community, spezialisiert auf Security & Vulnerability Management. Format hauptsächlich JSON, XML.

Nutzer: Security-Scanner (Snyk, Sonatype, etc.), agile Teams.

Für KMUs: CycloneDX ist pragmatischer für Schwachstellenmanagement, SPDX für behördliche Anforderungen. BSI TR-03183-2 (Version 2.1.0) verlangt mindestens CycloneDX 1.6 oder SPDX 3.0.1 und macht elf Angaben je Komponente zur Pflicht, darunter eine SHA-512-Prüfsumme. Viele Build-Tools (Maven, Gradle, npm, pip) erzeugen automatisch CycloneDX SBOMs.

Was gehört in eine SBOM?

Komponenten: Alle direkten Abhängigkeiten (z.B. Libraries, Frameworks) mit Namen, Version, Herkunft.

Transitive Abhängigkeiten: Wenn Sie Library A nutzen, die Library B nutzt, muss B auch dokumentiert sein.

Versionsangaben: Nicht „Log4j", sondern exakt „Apache Log4j 2.14.1".

Lizenzen: Welche Lizenz hat jede Komponente? (GPL? MIT? Proprietär?). Herkunft/Supplier: Woher kommt das Package? (Maven Central? npm Registry? privates Repo?). Patchstatus (optional): Wurde diese Version bereits gepatched? Schwachstellen-Referenzen (optional): Welche CVEs sind bekannt? Die SBOM sollte automatisch aus dem Build-System erzeugt werden, nicht manuell.

SBOM-Erzeugung: Tools und Integration

Automatisch im Build-Process:

  1. Maven (Java): maven-cyclonedx-plugin generiert SBOM automatisch bei jedem Build.
  2. Gradle (Java): gradle-cyclonedx, ebenso.
  3. npm (JavaScript): npm-sbom oder cyclonedx-npm erzeugt Dateien aller Dependencies.
  4. pip (Python): cyclonedx-bom generiert aus requirements.txt.
  5. .NET: CycloneDX.Module.Comet für NuGet.
  6. Go: syft oder cyclonedx-go. Auch große Security-Scanner wie Snyk, Sonatype Nexus, WhiteSource erzeugen SBOM-Export.

Für KMUs: Integrieren Sie SBOM-Generierung in ihre CI/CD-Pipeline, dann ist Ihre SBOM automatisch immer aktuell.

Praktisches Beispiel: SBOM nutzen für Patch-Planung

Szenario: CVE-2024-12345 wird public, betrifft Jackson (JSON-Library für Java) Version 2.15.0 bis 2.15.2. Sie haben eine SBOM. Prozess:

  1. Scanner liest CVE-Feed und SBOM.
  2. Findet „Jackson 2.15.1" in Applikation A und C.
  3. Erstellt automatisch Tickets: „Update Jackson auf 2.15.3 für App A, C".
  4. Entwickler können Patch sofort planen.
  5. Nach Deploy wird SBOM aktualisiert, Scanner erkennt: „CVE-2024-12345 für App A, C = fixed".

Ohne SBOM: Manuelles Suchen, Fehler, schlaflose Nächte.

Mit SBOM: Prozessiert automatisch.

SBOM allein reicht nicht: Verknüpfung mit CVE/CSAF/VEX

Eine SBOM ist eine Inventarliste, sie sagt: „Sie nutzen Log4j 2.14.1." Sie sagt aber nicht: „Log4j 2.14.1 hat CVE-2021-44228." Erst die Verknüpfung mit:

  1. CVE-Feeds (welche Schwachstellen gibt es?),
  2. CSAF/VEX-Advisories (für Kontext, Patches, Workarounds),
  3. EPSS/KEV (wie dringend?), ergibt das vollständige Bild.

Ein automatisierter Prozess: SBOM (Was nutzen wir?) + CVE-Feed (was ist kaputt?) + CSAF-Advisory (wie beheben?) = Patch-Liste. Das ist der Sinn von SBOM im Ökosystem.

VEX (Vulnerability Exploitability eXchange): SBOM-Erweiterung

VEX ist ein neues Format (basierend auf CSAF), das Hersteller nutzen, um auszusagen: „Mein Produkt enthält zwar Library X mit CVE-Y, ist aber nicht ausnutzbar, weil wir die Funktion nicht nutzen." Beispiel: Ihr Produkt nutzt OpenSSL, aber nur für Datei-Verschlüsselung. Eine neue OpenSSL-Lücke im TLS-Handshake betrifft Sie nicht. Mit VEX können Sie das dokumentieren und False Positives in Scannerberichten reduzieren.

Für KMUs: VEX wird zunehmend wichtig bei Compliance-Berichten (CRA verlangt es), ist aber noch nicht überall implementiert. BSI TR-03183-2 verbietet ausdrücklich, Schwachstelleninformationen direkt in die SBOM einzutragen. Dafür ist VEX zuständig, mehr dazu im Glossareintrag zu VEX.

SBOM-Beispiele: Reale SBOMs lesen

Google publiziert SBOMs für viele Produkte öffentlich, z.B. für Kubernetes. Red Hat bietet für jede Enterprise-Software eine SBOM. Die SBOMs sind meist im CycloneDX-JSON-Format und können maschinenlesbar gecrawlt werden.

Größe: Eine typische Enterprise-App kann eine SBOM mit 100 bis 500 Komponenten haben (direkte + transitive Dependencies). Eine große Applikation wie Chrome oder Firefox: 10.000+ Komponenten.

Praxis-Tool

Prüfe deine SBOM- und Dokumentationspflichten nach dem CRA

Zum CRA-Klartext →

Teil des Themenbereichs: Schwachstellen managen

Verwandte Begriffe

Quellen

Zuletzt aktualisiert: 2026-06-19

Häufige Fragen zu SBOM

Ist eine SBOM im Cyber Resilience Act verpflichtend?

Ja. Der Cyber Resilience Act (EU 2024/2847) verpflichtet Hersteller von Produkten mit digitalen Elementen zur Erstellung und Pflege einer maschinenlesbaren SBOM. Sie muss vor Marktplatzierung vorhanden sein, aktuell gehalten werden und auf Anfrage von Marktüberwachungsbehörden bereitgestellt werden können.

Welches Format sollte ich verwenden: SPDX oder CycloneDX?

CycloneDX ist pragmatischer für Schwachstellenmanagement und wird von den meisten Security-Scannern unterstützt; SPDX ist stärker auf Lizenzcompliance ausgerichtet. Die BSI TR-03183-2 verlangt mindestens CycloneDX 1.6 oder SPDX 3.0.1, mit elf Pflichtangaben je Komponente, u. a. einer SHA-512-Prüfsumme.

Was gehört in eine SBOM?

Alle direkten und transitiven Abhängigkeiten mit exakter Versionsnummer, Lizenz und Herkunft/Supplier. Optional zusätzlich Patchstatus und CVE-Referenzen. Die SBOM sollte automatisch aus dem Build-System erzeugt werden, nicht manuell gepflegt.

Was ist der Unterschied zwischen SBOM und VEX?

Die SBOM listet, welche Komponenten ein Produkt enthält. Sie sagt aber nicht, ob eine bekannte Schwachstelle in einer Komponente tatsächlich ausnutzbar ist. Das übernimmt VEX (Vulnerability Exploitability eXchange). BSI TR-03183-2 verbietet sogar ausdrücklich, Schwachstelleninformationen direkt in die SBOM einzutragen.

Wie hilft eine SBOM bei einem Vorfall wie Log4Shell?

Ohne SBOM müssen Teams bei einer neuen Schwachstelle manuell durchsuchen, ob und wo eine betroffene Komponente eingesetzt wird. Das kostet Tage. Mit SBOM lässt sich automatisiert gegen den CVE-Feed abgleichen und in Minuten feststellen, welche Anwendungen betroffen sind und ein Update brauchen.