SBOM: Das Wichtigste in Kürze Eine Software Bill of Materials (SBOM) ist ein maschinenlesbares Verzeichnis der Softwarekomponenten eines Produkts samt Abhängigkeiten im festgelegten Umfang. Der Cyber Resilience Act verlangt sie von Herstellern, deren Produkte in seinen Anwendungsbereich fallen. Die Hauptpflichten gelten ab dem 11.12.2027. Gängige Formate sind CycloneDX und SPDX. Unten finden Sie außerdem den SBOM-Qualitäts-Check in 10 Fragen, mit dem Sie erste Lücken Ihres SBOM-Prozesses erkennen. Autor: Roland Reif Was ist eine SBOM? Wird eine Schwachstelle in einer Open-Source-Bibliothek bekannt, müssen Hersteller schnell überprüfen können, ob ihre Produkte betroffen sind. Dafür müssen sie wissen, welche Komponenten in welcher Version enthalten sind und welche Produkte diese Komponenten verwenden. Eine aktuelle SBOM bildet dafür die Grundlage. Erst durch einen automatisierten Prozess, der die SBOMs den jeweiligen Releases zuordnet und mit aktuellen Schwachstellen abgleicht, lässt sich die Betroffenheit bewerten. Eine SBOM ist ein maschinenlesbares Verzeichnis der Komponenten einer Software innerhalb eines festgelegten Umfangs. Dazu gehören auch die Abhängigkeiten zwischen den Komponenten. Vereinfacht gesagt funktioniert eine SBOM wie eine Zutatenliste: Sie dokumentiert, welche Bibliotheken, Frameworks und weiteren Komponenten in welcher Version enthalten sind. Jede Komponente in einer SBOM muss eindeutig identifizierbar sein. Dazu dienen Name, Version und Angaben zum Komponentenhersteller oder -ersteller. Fehlende Angaben erschweren die eindeutige Zuordnung. Der erforderliche Umfang hängt von den geltenden Anforderungen ab. Der Cyber Resilience Act (CRA) verlangt eine SBOM, die mindestens die oberste Ebene der Abhängigkeiten abdeckt. Das bedeutet, dass alle direkten Abhängigkeiten einer Software erfasst werden müssen. Indirekte (transitive) Abhängigkeiten sind damit nicht automatisch abgedeckt. Die BSI TR-03183-2 beschreibt weitergehende technische Anforderungen an die Erstellung einer SBOM. Dazu gehören beispielsweise SHA-512-Hashwerte zur Integritätsprüfung und Angaben zu Distributionslizenzen, soweit sie für die jeweilige Beschreibung erforderlich sind. Diese Informationen helfen, Komponenten zu überprüfen und Lizenzanforderungen zu bewerten. Welche Anforderungen für Ihr Produkt gelten, hängt davon ab, welche gesetzlichen Vorgaben und technischen Profile anzuwenden sind. Wer braucht eine SBOM und ab wann ist sie Pflicht? Die SBOM-Pflicht betrifft Hersteller, deren Produkte mit digitalen Elementen in den Anwendungsbereich des CRA fallen. Der CRA verlangt von Herstellern, dass sie die Komponenten ihrer Produkte identifizieren und dokumentieren (Anhang I, Teil II, Nummer 1). Die SBOM muss in einem gebräuchlichen, maschinenlesbaren Format vorliegen und mindestens die oberste Ebene der Abhängigkeiten abdecken (Verordnung (EU) 2024/2847, Anhang I Teil II Nr. 1). Die entsprechenden Anforderungen gelten grundsätzlich ab dem 11. Dezember 2027. Für Produkte, die vor diesem Datum in Verkehr gebracht wurden, gelten die CRA-Anforderungen nur dann, wenn sie nachträglich wesentlich verändert werden. Außerdem: Wann genau welche CRA-Pflicht greift, zeigt unser Beitrag zu den CRA-Fristen. Eine Übersicht aller Anforderungen rund um Security-by-Design, Schwachstellenbehandlung und technische Dokumentation finden Sie in unserem Beitrag Anforderungen des Cyber Resilience Act. Auch vertragliche Anforderungen beachten Auch Kunden können eine SBOM vertraglich einfordern, unabhängig vom CRA-Status Ihres Produkts. Was ist der Inhalt einer SBOM? Eine SBOM enthält Informationen über die Softwarekomponenten eines Produkts und deren Abhängigkeiten. Welche Angaben erforderlich sind, hängt vom jeweiligen Anforderungsprofil ab. Die BSI TR-03183-2 legt für ihr technisches Profil unter anderem folgende Datenfelder fest: Ersteller der Komponente Name der Komponente Version der Komponente Abhängigkeiten zu anderen Komponenten Distributionslizenzen SHA-512-Hashwert der auslieferbaren Komponente Ersteller und Zeitstempel der SBOM CRA und technisches Profil unterscheiden Kennungen wie die Package URL (purl) unterstützen außerdem den Abgleich mit Datenbanken, soweit sie verfügbar sind. Der Cyber Resilience Act verlangt mindestens die oberste Ebene der Abhängigkeiten, also die direkten Abhängigkeiten des Produkts. Die BSI TR-03183-2 empfiehlt hingegen eine detailliertere Erfassung der Abhängigkeiten als der CRA. Sie ist eine technische Richtlinie, kein Gesetz. Daher gelten ihre Vorgaben nicht automatisch für jeden Hersteller. SBOM Spezifikationen: CycloneDX oder SPDX? Für SBOMs gibt es zwei etablierte Formate: CycloneDX und SPDX. Beide SBOM-Formate sind international anerkannte Standards mit unterschiedlichem Schwerpunkt. Die Unterschiede sind in der folgenden Tabelle dargestellt:KriteriumCycloneDXSPDXEntwickelt vonOWASPLinux FoundationStandardisierungECMA-424 (seit 2024)ISO/IEC 5962:2021 (Version 2.2.1)SchwerpunktSicherheits- und SchwachstellenmanagementLizenzmanagement und Open-Source-ComplianceBeide Formate haben unterschiedliche Schwerpunkte, ihre Einsatzbereiche überschneiden sich jedoch. CycloneDX wird häufig im Schwachstellenmanagement eingesetzt, während SPDX besonders für Lizenzmanagement und Open-Source-Compliance relevant ist. Entscheidend ist zunächst, welche Formate Ihre vorhandenen Tools unterstützen. Relevant sind hier beispielsweise Tools für die SBOM-Erstellung, das Schwachstellenmonitoring und die Lizenzprüfung. Nicht jedes Tool kann beide Formate gleichermaßen verarbeiten. Prüfen Sie außerdem, ob Kunden oder andere Anforderungen ein bestimmtes Format vorgeben. Wenn Ihre Build-Pipeline bereits zuverlässig SBOMs in einem unterstützten Format erzeugt, ist ein Wechsel ohne konkreten Anlass meist nicht notwendig. Beide Formate sind gebräuchlich und maschinenlesbar und werden von der BSI TR-03183-2 in den genannten Mindestversionen benannt. Die Wahl richtet sich nach Ihrem Einsatzzweck. SBOM Erstellung – Best Practice Eine SBOM sollte automatisiert im Build-Prozess erstellt und bei jedem Release aktualisiert werden. Fünf Schritte helfen bei der Umsetzung. 01 Scope festlegen Legen Sie fest, für welches Produkt, welche Version und welchen Auslieferungsstand eine SBOM erstellt werden soll. 02 Komponenten erfassen Erfassen Sie die Komponenten aus dem Build-Prozess. 03 Format wählen Entscheiden Sie zwischen CycloneDX und SPDX anhand der Kriterien aus dem vorigen Abschnitt. 04 Daten anreichern Ergänzen Sie Metadaten, wie Lizenzinformationen je Komponente, soweit das gewählte Profil sie verlangt; prüfen Sie die übrigen anwendbaren Felder. 05 Automatisieren und pflegen Binden Sie die SBOM-Erzeugung in die CI/CD-Pipeline ein, sodass jedes Release automatisch eine neue, aktuelle SBOM erzeugt. SBOM-Tools: Diese Kriterien helfen bei der Auswahl Für die Umsetzung dieser Schritte gibt es mehrere Tool-Kategorien und Lösungsansätze. Beispielsweise eignen sich Software-Composition-Analysis-Tools (SCA), Build- und Paketmanager-Plugins sowie Validierungs- und Konvertierungswerkzeuge. CI/CD-Integrationen übernehmen die automatisierte Ausführung dieser Werkzeuge im Build-Prozess. Bei der Auswahl eines SBOM-Tools helfen diese Kriterien: Unterstützung des gewählten Formats in der benötigten Spezifikationsversion Integration in die vorhandene Build- und Release-Pipeline Automatische Ermittlung von Hashwerten und Lizenzen Fähigkeit, auch Binärkomponenten und Drittanbieter-Bibliotheken ohne eigenen Quellcode zu erfassen Exportformate, die sich an Kunden- und Behördenanfragen anpassen lassen SBOM und VEX: Inventar und Bewertung ergänzen sich Eine SBOM listet auf, welche Komponenten ein Produkt enthält. VEX (Vulnerability Exploitability eXchange) bewertet darüber hinaus, ob eine konkrete Schwachstelle das Produkt tatsächlich betrifft. So kann der Hersteller beispielsweise dokumentieren, dass eine Schwachstelle im Produktkontext nicht ausnutzbar oder bereits behoben ist. VEX kann die Bewertung von Schwachstellen erleichtern, ist aber keine ausdrückliche Anforderung des CRA. SBOM-Qualitäts-Check in 10 Fragen Mit den folgenden Fragen können Sie prüfen, wie gut Ihre SBOM-Erstellung und -Pflege aufgestellt sind. Bewerten Sie jede Frage mit „Ja“ (1 Punkt), „Teilweise“ (0,5 Punkte) oder „Nein“ (0 Punkte). 1. Wird die SBOM bei jedem Release automatisch aus dem Build erzeugt? Quellenbezug: Best Practice 2. Enthält die SBOM zu jeder Komponente Name, Version und Komponentenhersteller bzw. -ersteller? Quellenbezug: BSI TR-03183-2 3. Sind verfügbare eindeutige Kennungen, etwa eine Package URL (PURL), angegeben? Quellenbezug: BSI TR-03183-2 4. Sind die Abhängigkeiten zwischen den Komponenten abgebildet? Quellenbezug: CRA / BSI TR-03183-2 5. Enthält die SBOM die nach dem gewählten Profil erforderlichen SHA-512-Hashwerte zur Integritätsprüfung? Quellenbezug: BSI TR-03183-2 6. Ist die Distributionslizenz je Komponente im erforderlichen Umfang dokumentiert? Quellenbezug: BSI TR-03183-2 7. Liegt die SBOM in einem maschinenlesbaren, gebräuchlichen Format vor, zum Beispiel CycloneDX oder SPDX? Quellenbezug: CRA Anhang I Teil II Nr. 1 8. Enthält die SBOM einen Zeitstempel und Angaben zum Ersteller? Quellenbezug: BSI TR-03183-2 9. Gibt es im Unternehmen eine benannte verantwortliche Person oder Rolle für Pflege und Aktualität der SBOM? Quellenbezug: Best Practice 10. Wird die SBOM bei neuen Releases und relevanten Änderungen aktualisiert? Quellenbezug: Best Practice Auswertung: Wo steht Ihre SBOM-Praxis? 8 bis 10 Punkte Viele der abgefragten Elemente sind vorhanden. Prüfen Sie alle mit „Teilweise“ oder „Nein“ bewerteten Punkte. 4 bis 7,5 Punkte Mehrere abgefragte Angaben oder Prozesse fehlen oder sind nur teilweise umgesetzt. 0 bis 3,5 Punkte Viele der abgefragten Elemente fehlen oder sind nur teilweise umgesetzt. Prüfen Sie Scope, Prozess und Format anhand der tatsächlich anwendbaren Anforderungen. Merksatz: Automatik, Format und Verantwortung Eine SBOM ist so gut wie der Prozess, der sie erzeugt. Wenn Sie nur drei Fragen sofort angehen können, beginnen Sie mit Frage 1, 7 und 9: Automatik, Format und Verantwortung. Integration in den Schwachstellenprozess Eine SBOM ist die Grundlage, um betroffene Produkte mit Schwachstellen schnell zu identifizieren. Dafür muss sie in den bestehenden Schwachstellenprozess integriert werden. Die SBOM sollte dabei für jedes relevante Release automatisiert im Build-Prozess erstellt, zugeordnet und auf Vollständigkeit sowie Format geprüft werden. Anschließend kann sie regelmäßig auf aktuelle Schwachstellen überprüft werden. So lassen sich auch Schwachstellen erkennen, die erst nach der Veröffentlichung eines Produkts bekannt werden. Sofern eine Komponente von einer Schwachstelle betroffen ist, muss entschieden werden, welche Maßnahmen erforderlich sind. Die SBOM unterstützt diese Analyse, ersetzt aber weder die technische Bewertung noch die Entscheidung über geeignete Maßnahmen. Für einen zuverlässigen Ablauf sollten Zuständigkeiten für die SBOM-Erstellung, die Bewertung von Schwachstellen und die Umsetzung von Maßnahmen festgelegt sein. Typische Fehler bei der SBOM-Erstellung Bei der Einführung und Pflege von SBOMs treten häufig dieselben Fehler auf. Fünf Fehlerbilder sollten Sie bei der SBOM-Einführung kennen. Zu jedem gehört eine Gegenmaßnahme. Die SBOM wird einmalig erzeugt, aber nicht aktualisiert. Gegenmaßnahme: SBOM-Erzeugung fest in die CI/CD-Pipeline einbauen, sodass jedes Release automatisch eine neue Version erzeugt. Die SBOM erfasst nicht alle erforderlichen Abhängigkeiten. Gegenmaßnahme: Prüfen, ob die SBOM den geforderten Umfang abdeckt. Der CRA verlangt mindestens die direkten Abhängigkeiten des Produkts. Die BSI TR-03183-2 beschreibt weitergehende Anforderungen an die Erfassung von Abhängigkeiten. Erforderliche Angaben wie SHA-512-Hashwerte fehlen. Gegenmaßnahme: Hash-Erzeugung im Build-Prozess aktivieren. Binärdateien oder Komponenten von Drittanbietern fehlen. Gegenmaßnahme: Die SBOM nicht nur aus dem Quellcode ableiten, sondern bei Bedarf auch das fertige Softwarepaket analysieren. Zusätzlich sollten erforderliche SBOMs von Zulieferern eingeholt werden. Die SBOM wird mit einem Schwachstellenscan verwechselt. Gegenmaßnahme: Die SBOM als Inventar der Softwarekomponenten nutzen und sie regelmäßig mit aktuellen Schwachstelleninformationen abgleichen. VEX kann ergänzend dokumentieren, ob eine konkrete Schwachstelle ein Produkt betrifft. FAQ: Häufige Fragen zur SBOM Was ist eine SBOM? Eine SBOM (Software Bill of Materials) ist ein maschinenlesbares Verzeichnis der Softwarekomponenten und Abhängigkeiten eines Produkts innerhalb eines festgelegten Umfangs. Sie dokumentiert, welche Bibliotheken, Frameworks und Module in welcher Version enthalten sind. Damit ist sie die Grundlage für Software Supply Chain Security, also die Absicherung der eigenen Software-Lieferkette. Ist eine SBOM Pflicht? Ja, für Hersteller, deren Produkte mit digitalen Elementen in den Anwendungsbereich des CRA fallen, ergibt sich die SBOM-Pflicht aus dem Cyber Resilience Act (Anhang I Teil II Nummer 1). Die Hauptpflichten der Verordnung gelten ab dem 11.12.2027. Die BSI TR-03183-2 konkretisiert die technischen Anforderungen an SBOMs, ist aber selbst kein Gesetz. Was ist der Unterschied zwischen CycloneDX und SPDX? CycloneDX stammt aus dem OWASP-Umfeld und wurde als ECMA-424 standardisiert. In der Praxis wird es häufig im Sicherheits- und Schwachstellenmanagement eingesetzt. SPDX stammt von der Linux Foundation und wurde als ISO/IEC 5962:2021 standardisiert. Es wird besonders für Lizenzmanagement und Open-Source-Compliance genutzt. Beide sind etablierte, maschinenlesbare SBOM-Formate. Muss ich die SBOM veröffentlichen? Nein, der CRA verlangt keine generelle öffentliche Veröffentlichung. Die SBOM ist Teil der technischen Dokumentation und muss auf begründetes Verlangen einer Marktüberwachungsbehörde vorgelegt werden. Kunden können die Bereitstellung einer SBOM unabhängig davon vertraglich vereinbaren. Was ist der Unterschied zwischen SBOM und VEX? Die SBOM listet, welche Komponenten in einem Produkt enthalten sind. VEX (Vulnerability Exploitability eXchange) bewertet, ob eine konkrete Schwachstelle dieses Produkt tatsächlich betrifft. VEX kann die Bewertung von Schwachstellen erleichtern, ist aber keine ausdrückliche Anforderung des CRA. Die SBOM liefert die Grundlage für diese Bewertung. Brauche ich eine SBOM für Open-Source-Komponenten? Ja, Open-Source-Komponenten gehören genauso in die SBOM wie kommerzielle Komponenten. Bei Open Source ist die Lizenzinformation wichtig, weil sich daraus rechtliche Pflichten für die eigene Software ergeben können. Das Profil der BSI TR-03183-2 verlangt Lizenzangaben unabhängig davon, ob eine Komponente Open Source oder proprietär ist. Wie oft muss ich die SBOM aktualisieren? Eine SBOM sollte bei jeder neuen Version oder jeder relevanten Änderung an den Komponenten aktualisiert werden. Die Automatisierung im Build-Prozess hilft dabei, dass die SBOM den tatsächlichen Softwarestand abbildet. Anschließend sollte sie regelmäßig mit aktuellen Schwachstelleninformationen abgeglichen werden, damit auch neu bekannt gewordene Schwachstellen erkannt werden können. Fazit Eine SBOM dokumentiert einen bestimmten Softwarestand und sollte im Build-Prozess automatisiert erzeugt werden. Ob CycloneDX oder SPDX das richtige Format ist, hängt vom Einsatzzweck und der vorhandenen Toollandschaft ab. Mit dem Qualitäts-Check in 10 Fragen erkennen Sie erste Lücken Ihrer SBOM-Praxis; eine Konformitätsprüfung ersetzt er nicht. Wie weit trägt Ihre SBOM-Praxis für den CRA? Sie wollen wissen, wie weit Ihre SBOM-Praxis für den Cyber Resilience Act trägt? Sprechen Sie mit unseren CRA-Expertinnen und -Experten. Rechtlicher Hinweis Dieser Beitrag ist keine Rechtsberatung. Er ersetzt keine Einzelfallprüfung durch eine Rechtsanwältin oder einen Rechtsanwalt. Quellen Verordnung (EU) 2024/2847 des Europäischen Parlaments und des Rates vom 23. Oktober 2024 (Cyber Resilience Act), Art. 13 Abs. 22, Art. 71, Anhang I Teil II Nr. 1 und Anhang VII Nr. 2 Buchstabe b (2024). EUR-Lex: Verordnung (EU) 2024/2847Bundesamt für Sicherheit in der Informationstechnik: Technische Richtlinie TR-03183-2, Cyber-Resilienz-Anforderungen an Hersteller und Produkte, Teil 2: Software Bill of Materials (SBOM), Version 2.1.0 (20.08.2025). BSI: TR-03183National Telecommunications and Information Administration (NTIA): The Minimum Elements For a Software Bill of Materials (SBOM) (2021). NTIA: SBOM Minimum ElementsCybersecurity and Infrastructure Security Agency (CISA): Vulnerability Exploitability eXchange (VEX), Use Cases (2022). CISA: VEX Use CasesEcma International: ECMA-424, CycloneDX Bill of Materials Specification (2024). Ecma International: ECMA-424ISO/IEC: ISO/IEC 5962:2021, Information technology: SPDX Specification V2.2.1 (2021). ISO/IEC 5962:2021 < Zurück zur Übersicht IT Security
2. Enthält die SBOM zu jeder Komponente Name, Version und Komponentenhersteller bzw. -ersteller? Quellenbezug: BSI TR-03183-2
3. Sind verfügbare eindeutige Kennungen, etwa eine Package URL (PURL), angegeben? Quellenbezug: BSI TR-03183-2
5. Enthält die SBOM die nach dem gewählten Profil erforderlichen SHA-512-Hashwerte zur Integritätsprüfung? Quellenbezug: BSI TR-03183-2
6. Ist die Distributionslizenz je Komponente im erforderlichen Umfang dokumentiert? Quellenbezug: BSI TR-03183-2
7. Liegt die SBOM in einem maschinenlesbaren, gebräuchlichen Format vor, zum Beispiel CycloneDX oder SPDX? Quellenbezug: CRA Anhang I Teil II Nr. 1
9. Gibt es im Unternehmen eine benannte verantwortliche Person oder Rolle für Pflege und Aktualität der SBOM? Quellenbezug: Best Practice
10. Wird die SBOM bei neuen Releases und relevanten Änderungen aktualisiert? Quellenbezug: Best Practice
8 bis 10 Punkte Viele der abgefragten Elemente sind vorhanden. Prüfen Sie alle mit „Teilweise“ oder „Nein“ bewerteten Punkte.
0 bis 3,5 Punkte Viele der abgefragten Elemente fehlen oder sind nur teilweise umgesetzt. Prüfen Sie Scope, Prozess und Format anhand der tatsächlich anwendbaren Anforderungen.
Die SBOM wird einmalig erzeugt, aber nicht aktualisiert. Gegenmaßnahme: SBOM-Erzeugung fest in die CI/CD-Pipeline einbauen, sodass jedes Release automatisch eine neue Version erzeugt.
Die SBOM erfasst nicht alle erforderlichen Abhängigkeiten. Gegenmaßnahme: Prüfen, ob die SBOM den geforderten Umfang abdeckt. Der CRA verlangt mindestens die direkten Abhängigkeiten des Produkts. Die BSI TR-03183-2 beschreibt weitergehende Anforderungen an die Erfassung von Abhängigkeiten.
Erforderliche Angaben wie SHA-512-Hashwerte fehlen. Gegenmaßnahme: Hash-Erzeugung im Build-Prozess aktivieren.
Binärdateien oder Komponenten von Drittanbietern fehlen. Gegenmaßnahme: Die SBOM nicht nur aus dem Quellcode ableiten, sondern bei Bedarf auch das fertige Softwarepaket analysieren. Zusätzlich sollten erforderliche SBOMs von Zulieferern eingeholt werden.
Die SBOM wird mit einem Schwachstellenscan verwechselt. Gegenmaßnahme: Die SBOM als Inventar der Softwarekomponenten nutzen und sie regelmäßig mit aktuellen Schwachstelleninformationen abgleichen. VEX kann ergänzend dokumentieren, ob eine konkrete Schwachstelle ein Produkt betrifft.