SBOM - Software Bill of Materials
Software-Stückliste
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):
- SBOM muss vor Marktplatzierung vorhanden sein, maschinenlesbar, und aktuell gehalten werden.
- Die BSI TR-03183-2 konkretisiert Anforderungen für den deutschen Markt.
- Auf Anfrage von Marktüberwachungsbehörden muss die SBOM bereitgestellt werden.
- 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 akzeptiert beide. 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 – B muss 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:
- Maven (Java): maven-cyclonedx-plugin – generiert SBOM automatisch bei jedem Build.
- Gradle (Java): gradle-cyclonedx – ebenso.
- npm (JavaScript): npm-sbom oder cyclonedx-npm – erzeugt Dateien aller Dependencies.
- pip (Python): cyclonedx-bom – generiert aus requirements.txt.
- .NET: CycloneDX.Module.Comet für NuGet.
- 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–2.15.2. Sie haben eine SBOM. Prozess:
- Scanner liest CVE-Feed und SBOM.
- Findet „Jackson 2.15.1" in Applikation A und C.
- Erstellt automatisch Tickets: „Update Jackson auf 2.15.3 für App A, C".
- Entwickler können Patch sofort planen.
- 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:
- CVE-Feeds (welche Schwachstellen gibt es?),
- CSAF/VEX-Advisories (für Kontext, Patches, Workarounds),
- 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.
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–500 Komponenten haben (direkte + transitive Dependencies). Eine große Applikation wie Chrome oder Firefox: 10.000+ Komponenten.