SBOM-Management für die Software-Lieferkette

Zwei offene Formate dominieren die Praxis. CycloneDX stammt aus der OWASP-Community und wird über das Ecma-Komitee TC54 international standardisiert: Version 1.6 wurde im Juni 2024 als ECMA-424 (1. Edition) veröffentlicht, die im Oktober 2025 erschienene Version 1.7 im Dezember 2025 als ECMA-424 (2. Edition) – mit erweiterter Modellierung u. a. für kryptografische Artefakte und ML-Modelle. SPDX wird unter dem Dach der Linux Foundation entwickelt; die ISO/IEC 5962:2021 normiert die Version 2.2.1, während die aktuelle Spezifikation 3.0.1 (Dezember 2024) das ISO-Verfahren als ISO/IEC DIS 5962 durchläuft. SPDX hat seine Wurzeln im Lizenz-Compliance-Umfeld, CycloneDX ist stärker auf Security-Anwendungsfälle ausgerichtet – beide erfüllen die CRA-Anforderung eines „gängigen und maschinenlesbaren Formats“.

Die NTIA definierte 2021 erstmals Mindestbestandteile einer SBOM in drei Kategorien: Datenfelder (u. a. Lieferant, Komponentenname, Version, eindeutige Identifikatoren, Abhängigkeitsbeziehungen, SBOM-Autor, Zeitstempel), Automatisierungsunterstützung und begleitende Prozesse. Im Juli 2026 haben CISA, NSA, FBI und internationale Partnerbehörden die „2026 Minimum Elements for a SBOM“ veröffentlicht, die die NTIA-Fassung ablösen. Neu aufgenommen wurden u. a. Komponenten-Hashes, Lizenzangaben, der Name des Generierungswerkzeugs und der Generierungskontext; bestehende Felder wurden präzisiert und einheitlicher benannt. Die Mindestinhalte gelten ausdrücklich als Untergrenze – je nach Einsatzzweck sind zusätzliche Angaben sinnvoll.

Der verlässlichste Zeitpunkt für die SBOM-Erzeugung ist der Build: Dort sind alle aufgelösten Abhängigkeiten inklusive exakter Versionen bekannt, die weder eine reine Quellcode-Analyse noch eine nachträgliche Binäranalyse vollständig rekonstruieren kann. In der Praxis übernehmen das Plugins für Paketmanager und Build-Systeme oder Generatoren wie cdxgen und Syft, eingebunden als fester Schritt der CI/CD-Pipeline. Jeder Release-Stand erhält so eine eigene, versionierte SBOM, die zusammen mit den Build-Artefakten abgelegt und idealerweise signiert wird. Der in den CISA-Elements 2026 geforderte Generierungskontext macht zudem transparent, in welcher Lebenszyklusphase eine SBOM entstanden ist.

Ihren Wert entfaltet eine SBOM erst durch kontinuierliche Korrelation mit Schwachstellendaten aus Quellen wie NVD, OSV oder GitHub Advisories – so lässt sich bei einer neuen CVE unmittelbar beantworten, welche Produkte betroffene Komponenten enthalten. Da eine verwundbare Komponente nicht automatisch ein verwundbares Produkt bedeutet, ergänzt VEX (Vulnerability Exploitability eXchange) die SBOM um maschinenlesbare Hersteller-Aussagen zur tatsächlichen Betroffenheit; die CISA hat dafür im April 2023 Mindestanforderungen publiziert. Als Austauschformate dienen das Common Security Advisory Framework (CSAF 2.0, seit November 2022 OASIS-Standard, mit eigenem VEX-Profil) sowie CycloneDX mit eingebettetem VEX. Richtig eingesetzt reduziert diese Kombination Fehlalarme erheblich und fokussiert die Behebung auf tatsächlich ausnutzbare Schwachstellen.

Der Cyber Resilience Act (Verordnung (EU) 2024/2847, in Kraft seit 10. Dezember 2024) macht die SBOM zur Pflicht: Anhang I Teil II verlangt von Herstellern, Schwachstellen und Komponenten zu dokumentieren, einschließlich einer Software-Stückliste in einem gängigen, maschinenlesbaren Format, die mindestens die obersten Abhängigkeiten (Top-Level Dependencies) abdeckt. Die SBOM ist Teil der technischen Dokumentation und Marktüberwachungsbehörden auf Verlangen vorzulegen; eine Veröffentlichungspflicht besteht nicht. Die Hauptpflichten gelten ab 11. Dezember 2027, Meldepflichten bereits ab 11. September 2026. Das BSI konkretisiert die Anforderungen in der Technischen Richtlinie TR-03183 Teil 2 (Version 2.1.0, August 2025) mit formalen und fachlichen Vorgaben je Datenfeld – inklusive Zuordnungsempfehlungen zu SPDX und CycloneDX sowie seit Version 2.1.0 der Behandlung virtueller und referenzierter Komponenten.

Für den laufenden Betrieb hat sich das Muster einer zentralen SBOM-Plattform etabliert, für das OWASP Dependency-Track das bekannteste Open-Source-Beispiel ist. Die Plattform konsumiert und produziert CycloneDX-SBOMs und -VEX-Dokumente, inventarisiert Komponenten über alle Projekte und Versionen hinweg und gleicht sie kontinuierlich gegen Schwachstellenquellen wie NVD, OSV, GitHub Advisories oder Snyk ab. Eine Policy Engine setzt Sicherheits-, Lizenz- und Betriebsrichtlinien automatisiert durch; das API-first-Design erlaubt die direkte Anbindung an CI/CD-Pipelines. Entscheidend ist der Paradigmenwechsel: Statt punktueller Scans wird das gesamte Portfolio bei jeder neuen Schwachstellenmeldung automatisch neu bewertet.