Leitfaden Stand 7. Oktober 2026 Lesezeit 10 Min.

SBOM nach CRA: Pflicht, Inhalt, Format und BSI TR-03183-2

Eine Software-Stückliste ist die Inventarliste der Software in einem Produkt. Der Cyber Resilience Act verlangt sie von jedem Hersteller, schreibt aber kein Format vor. Diese Seite erklärt die Pflicht, die Empfehlung des BSI und den Zusammenhang mit der Meldepflicht.

Der Cyber Resilience Act verpflichtet Hersteller, eine Software-Stückliste zu führen (Anhang I Teil II Nummer 1). Das ist eine maschinenlesbare Liste der Software-Bausteine, aus denen ein Produkt besteht, mindestens mit den obersten Abhängigkeiten. Veröffentlichen muss der Hersteller diese Liste nicht. Sie gehört zur technischen Dokumentation und ist der Marktüberwachungsbehörde auf begründetes Verlangen vorzulegen. Ein verbindliches Format nennt die Verordnung nicht. In Deutschland beschreibt die Technische Richtlinie BSI TR-03183-2, wie eine brauchbare Stückliste aussieht: CycloneDX ab Version 1.6 oder SPDX ab Version 3.0.1, mit festen Pflichtfeldern je Komponente.

Das Wichtigste

Die SBOM ist Pflicht für jedes Produkt mit digitalen Elementen, als Teil der Schwachstellenbehandlung (Anhang I Teil II Nummer 1) und der technischen Dokumentation (Anhang VII Nummer 2 Buchstabe b).
Die Verordnung verlangt ein gängiges, maschinenlesbares Format und mindestens die obersten Abhängigkeiten. Mehr Tiefe empfiehlt BSI TR-03183-2.
Eine Veröffentlichungspflicht gibt es nicht (Erwägungsgrund 77). Sehen darf die SBOM die Marktüberwachungsbehörde auf begründetes Verlangen.
Schwachstellen gehören nicht in die SBOM. Dafür gibt es VEX und CSAF.
Ohne aktuelle SBOM lässt sich bei einer Schwachstelle in einer Fremdkomponente nicht schnell klären, ob das eigene Produkt betroffen ist. Diese Zeit geben die Meldefristen nicht her.

Was ist eine SBOM und warum verlangt der CRA sie?

SBOM steht für Software Bill of Materials, auf Deutsch Software-Stückliste. Der Begriff ist der Stückliste aus der Fertigung nachgebildet. So wie eine Maschine aus Baugruppen und Zukaufteilen besteht, besteht die Software eines Produkts aus eigenem Code, Bibliotheken von Dritten, Open-Source-Bausteinen und oft einem Betriebssystem. Die SBOM zählt diese Bausteine mit Name, Version und Hersteller auf, in einer Form, die Programme lesen können.

Der Grund für die Pflicht ist praktisch. Die meisten Schwachstellen werden in Bausteinen entdeckt, die viele Hersteller gemeinsam nutzen. Wird eine Lücke in einer verbreiteten Bibliothek bekannt, muss jeder Hersteller wissen, in welchen Produkten er sie einsetzt. Mit Liste ist das in Minuten beantwortet. Dazu passt die Sorgfaltspflicht nach Artikel 13 Absatz 5: Zugekaufte oder frei verfügbare Komponenten dürfen die Sicherheit des Produkts nicht beeinträchtigen.

Was genau verlangt die Verordnung?

Die Pflicht steht in Anhang I Teil II Nummer 1. Hersteller müssen Schwachstellen und Komponenten ihres Produkts ermitteln und dokumentieren,

u. a. durch Erstellung einer Software-Stückliste in einem gängigen maschinenlesbaren Format, aus der zumindest die obersten Abhängigkeiten der Produkte hervorgehen
Anhang I Teil II Nummer 1 CRA

Drei Dinge folgen daraus. Erstens: Die SBOM ist ein Datenformat, keine Tabelle in einer Textverarbeitung. Zweitens: Die Untergrenze sind die obersten Abhängigkeiten, also die Komponenten, die das Produkt direkt einbindet. Drittens: Die SBOM ist Teil der technischen Dokumentation (Anhang VII Nummer 2 Buchstabe b), die der Marktüberwachungsbehörde auf begründetes Verlangen vorzulegen ist (Anhang VII Nummer 8).

Format, Felder und Tiefe jenseits der obersten Ebene regelt die Verordnung nicht. Artikel 13 Absatz 24 ermächtigt die Kommission, beides per Durchführungsrechtsakt festzulegen. Ein solcher Rechtsakt ist am 7. Oktober 2026 nicht erlassen.

Wer darf die SBOM sehen?

Die SBOM ist keine Veröffentlichung und keine Beilage für Kunden. Erwägungsgrund 77 sagt es ausdrücklich:

Die Hersteller sollten nicht verpflichtet sein, die Software-Stückliste zu veröffentlichen.
Erwägungsgrund 77 CRA

Wer die Liste verlangen darf, ergibt sich aus mehreren Stellen der Verordnung:

Die Marktüberwachungsbehörde auf begründetes Verlangen (Anhang VII Nummer 8, Artikel 53). In Deutschland soll das nach dem Entwurf des Durchführungsgesetzes das BSI sein.
Die notifizierte Stelle, wenn das Produkt eine Drittprüfung durchläuft (Module B oder H nach Anhang VIII).
Die Gruppe der Marktüberwachungsbehörden (ADCO) nur mittelbar: Behörden können SBOMs für unionsweite Abhängigkeitsbewertungen anfordern, geben sie aber nur anonymisiert und aggregiert weiter (Artikel 13 Absatz 25, Erwägungsgrund 22).
Nutzer haben keinen Anspruch. Wer die SBOM freiwillig bereitstellt, nennt in den Nutzerinformationen den Fundort (Anhang II Nummer 9).

Kunden fragen trotzdem zunehmend nach der SBOM, vor allem Betreiber, die selbst unter NIS2 fallen. Das ist dann Vertragssache, keine Pflicht aus dem CRA.

Was empfiehlt BSI TR-03183-2?

Teil 2 der Technischen Richtlinie TR-03183 des BSI (Version 2.1.0 vom 20. August 2025) beschreibt, was eine SBOM enthalten soll. Die Richtlinie ist freiwillig, aber die einzige behördliche Konkretisierung in Deutschland, und sie verweist selbst auf den CRA. Wer ihr folgt, kann begründen, warum seine SBOM "gängig" und vollständig genug ist.

Format

Zwei Formate sind zulässig: CycloneDX ab Version 1.6 oder SPDX ab Version 3.0.1, jeweils als JSON oder XML und nur in offiziell veröffentlichten Versionen der Spezifikation (Kapitel 4). Beide sind offene Standards, die gängige Werkzeuge erzeugen und lesen. Welches ein Hersteller wählt, ist zweitrangig; wichtig ist, dass er über alle Produkte beim selben bleibt.

Pflichtfelder

Je ausgelieferter Softwareversion gehört eine eigene SBOM in die Dokumentation; ändert sich die Software, entsteht eine neue (Kapitel 3.1). Kapitel 5.2 legt fest, was sie mindestens enthält:

Ebene	Pflichtfeld	Hinweis aus der Richtlinie
SBOM	Ersteller der SBOM	E-Mail-Adresse, ersatzweise URL
SBOM	Zeitstempel der Erstellung	UTC empfohlen
Komponente	Ersteller der Komponente	E-Mail-Adresse oder URL
Komponente	Name	Ersatzweise der Dateiname
Komponente	Version	Semantische Versionierung oder Kalenderversion, ersatzweise das Änderungsdatum
Komponente	Dateiname	Name der ausgelieferten Datei
Komponente	Abhängigkeiten	Zu anderen Komponenten, mit Angabe, ob die Liste vollständig ist
Komponente	Distributionslizenzen	Als SPDX-Lizenzkennung
Komponente	Hashwert	SHA-512 der auslieferbaren Komponente
Komponente	Eigenschaften	Ob die Komponente ausführbar, ein Archiv oder strukturiert ist

Falls vorhanden, kommen die URI der SBOM, die URI von Quellcode und ausgelieferter Form, Kennungen wie CPE oder purl und die Originallizenzen dazu (Kapitel 5.2.3 und 5.2.4). Optional sind effektive Lizenz, Quellcode-Hash und die security.txt des Komponentenherstellers (Kapitel 5.2.5).

Tiefe

Hier geht die Richtlinie über den CRA hinaus. Kapitel 5.1 verlangt, jede Komponente im Lieferumfang auf jedem Pfad rekursiv aufzulösen, bis einschließlich der ersten Komponente außerhalb des Lieferumfangs; diese Fremdkomponente ist mindestens mit Ersteller, Name und Version zu identifizieren. Anders gesagt: die eigenen Bausteine vollständig, dazu die erste Ebene dessen, was von außen kommt. Kapitel 8.3 unterscheidet Top-Level-SBOM (eine Ebene), n-Level-SBOM und transitive SBOM. SBOMs von Zulieferkomponenten dürfen referenziert statt eingebettet werden, wenn sie selbst der Richtlinie entsprechen.

Gehören Schwachstellen in die SBOM?

Nein. Die SBOM ist eine statische Liste je Version. Welche Schwachstellen in den Komponenten bekannt sind und ob das Produkt betroffen ist, ändert sich laufend und gehört in getrennte Dokumente. Die Richtlinie schließt Schwachstelleninformationen in der SBOM aus (Kapitel 3.1) und verweist auf zwei Formate:

VEX (Vulnerability Exploitability eXchange): eine maschinenlesbare Aussage des Herstellers, ob eine bekannte Schwachstelle in einer Komponente das Produkt tatsächlich betrifft.
CSAF (Common Security Advisory Framework): ein maschinenlesbares Format für Sicherheitshinweise mit Schwachstelle, betroffenen Produkten und Abhilfe.

Die SBOM sagt, was drin ist. VEX und CSAF sagen, was davon ein Problem ist und was der Hersteller dagegen tut.

Was hat die SBOM mit der Meldepflicht zu tun?

Mehr, als der Wortlaut vermuten lässt. Die Meldepflicht nach Artikel 14 greift bei einer aktiv ausgenutzten Schwachstelle im eigenen Produkt, mit einer Frühwarnung binnen 24 Stunden ab Kenntnis. Die meisten Schwachstellen, von denen ein Hersteller erfährt, betreffen aber zunächst eine Fremdkomponente: Ein Sicherheitshinweis zu einer Bibliothek erscheint, ein Kunde fragt nach, ein Sicherheitsforscher meldet eine Lücke in einem Baustein. Die erste Frage lautet dann immer: Steckt diese Komponente in dieser Version in unserem Produkt?

Mit einer gepflegten SBOM je Version ist das ein Abgleich. Ohne SBOM ist es eine Recherche über Tage, und in diesen Tagen läuft die Frist, sobald sich herausstellt, dass die Lücke ausgenutzt wird. Die Sorgfaltspflicht setzt dasselbe voraus. Erwägungsgrund 34 nennt den Abgleich gegen die europäische Schwachstellendatenbank (EUVD) oder andere öffentliche Datenbanken. Artikel 13 Absatz 6 verpflichtet den Hersteller, eine Schwachstelle in einer integrierten Komponente dem Komponentenhersteller zu melden und selbst zu beheben.

Die Bewertung läuft laut Kommissionsleitlinie (Sekundärquelle) in drei Fragen: Ist die verwundbare Komponente enthalten? Ist sie erreichbar? Wird die Lücke ausgenutzt? Nur die letzte Frage entscheidet über die Meldepflicht; ein veröffentlichter CVE-Eintrag (die öffentliche Kennung einer bekannten Schwachstelle) allein löst sie nicht aus. Das Ergebnis "enthalten, aber nicht betroffen" gehört als VEX oder CSAF nach außen, nicht in die SBOM.

Bezug zur Bereitschaft

CRA Response Center setzt nach der SBOM an: Meldungen an die Sicherheitsadresse werden geprüft, die Rufkette geweckt, die Fristen-Uhren gestartet, jeder Schritt protokolliert. Die Betroffenheitsprüfung gelingt nur, wenn der Hersteller je Version weiß, was in seinem Produkt steckt. Die SBOM ist die Grundlage, auf der 24 Stunden überhaupt reichen.

Welche Werkzeuge braucht ein Hersteller?

Eine SBOM von Hand zu pflegen, scheitert spätestens bei der zweiten Version. Fünf Werkzeugkategorien greifen ineinander:

Erzeugung im BuildErweiterungen des Paketmanagers, Container-Scanner oder Analysewerkzeuge für Firmware ohne Quellcode erzeugen die SBOM bei jedem Build.
Verwaltung und AblageEin Repository hält je Release die zugehörige SBOM vor, versioniert und auffindbar.
Abgleich gegen SchwachstellendatenbankenWerkzeuge zur Software-Composition-Analyse gleichen die Liste laufend gegen Schwachstellendatenbanken wie die EUVD und gegen Herstellerhinweise ab.
VEX- und CSAF-ErzeugungDas Ergebnis der Bewertung wird als VEX-Aussage oder CSAF-Hinweis erfasst und verteilt.
ValidierungPrüfprogramme kontrollieren, ob eine SBOM der Spezifikation entspricht und die Pflichtfelder der TR-03183-2 enthält.

Entscheidend ist weniger das Werkzeug als die Regel: Keine Version verlässt das Haus ohne SBOM.

Typische Fehler

Eine SBOM für "das Produkt" statt je Version. Wer nur die aktuelle Version kennt, kann für Kunden mit älteren Ständen keine Betroffenheit klären.
Schwachstellen in die SBOM schreiben. Die Liste ist dadurch sofort veraltet. Schwachstellenstatus gehört in VEX oder CSAF.
Nur oberste Abhängigkeiten, ohne Angabe der Vollständigkeit. Fehlt die Aussage, ob die Abhängigkeitsliste vollständig ist, weiß niemand, ob eine Komponente fehlt oder nicht enthalten ist.
SBOM einmal erstellt, nie aktualisiert. Jeder Komponentenwechsel, auch ein Bibliotheks-Update, erzeugt eine neue Version mit neuer SBOM.
Zulieferer-Firmware ohne SBOM akzeptieren. Die Sorgfaltspflicht nach Artikel 13 Absatz 5 greift auch für zugekaufte Software.

Was bleibt offen?

Am 7. Oktober 2026 hat die Kommission von der Ermächtigung in Artikel 13 Absatz 24 keinen Gebrauch gemacht; ob ein verbindliches Format kommt, ist offen. Die harmonisierte Norm zur Schwachstellenbehandlung (prEN 40000-1-3) ist nicht im Amtsblatt zitiert; ob sie andere Anforderungen an Tiefe oder Felder stellt als die Richtlinie des BSI, lässt sich nicht sagen.

Häufige Fragen

Ist eine SBOM wirklich Pflicht?

Ja. Anhang I Teil II Nummer 1 verlangt sie als Teil der Schwachstellenbehandlung, Anhang VII Nummer 2 Buchstabe b als Teil der technischen Dokumentation, unabhängig von der Produktklasse.

Welches Format muss die SBOM haben?

Die Verordnung sagt nur "gängig und maschinenlesbar". BSI TR-03183-2 nennt CycloneDX ab Version 1.6 oder SPDX ab Version 3.0.1, als JSON oder XML. Ein verbindliches Format per Durchführungsrechtsakt gibt es bisher nicht.

Wie tief muss die SBOM gehen?

Die Verordnung verlangt mindestens die obersten Abhängigkeiten. Die Richtlinie des BSI geht weiter: alle eigenen Komponenten vollständig, dazu je Pfad die erste Fremdkomponente mit Ersteller, Name und Version.

Muss ich die SBOM meinen Kunden geben?

Nein. Erwägungsgrund 77 nimmt die Veröffentlichung ausdrücklich aus. Wer sie freiwillig bereitstellt, nennt in den Nutzerinformationen den Fundort (Anhang II Nummer 9). Kundenwünsche danach sind Vertragssache.

Gehören bekannte Schwachstellen in die SBOM?

Nein. Die Richtlinie schließt das aus, weil die SBOM eine statische Liste je Version ist. Der Schwachstellenstatus gehört in VEX-Aussagen oder CSAF-Sicherheitshinweise.

Brauche ich eine SBOM für Hardware ohne eigene Software?

Nur, wenn Code enthalten ist. Firmware zählt als Software und braucht eine SBOM.

Weiterlesen

Quellen

Verordnung (EU) 2024/2847 (Cyber Resilience Act), Artikel 13 Absatz 5, 6, 24 und 25, Artikel 53, Anhang I Teil II Nummer 1, Anhang II Nummer 9, Anhang VII Nummer 2 Buchstabe b und Nummer 8, Erwägungsgründe 22, 34 und 77, Amt für Veröffentlichungen der EU, 20. November 2024.
BSI TR-03183-2 Software Bill of Materials (SBOM), Version 2.1.0, Kapitel 3.1, 4, 5.1, 5.2 und 8.3, Bundesamt für Sicherheit in der Informationstechnik, 20. August 2025.
Germany BSI SBOM Guidelines, FOSSA, 2025.
The new CRA guidance in practice, Schutzwerk, 2026.