SBOM (Software-Stueckliste) — was der Cyber Resilience Act verlangt

Eine Software-Stueckliste ist ein unspektakulaeres Artefakt mit erheblicher Wirkung. Sie ist eine Liste: aus welchen Komponenten die Software eines Produkts besteht, in welchen Versionen, von welchen Lieferanten, unter welchen Lizenzen. Bis vor Kurzem war sie eine interne Bequemlichkeit der Entwicklung. Mit der Verordnung (EU) 2024/2847 — dem Cyber Resilience Act — wird sie zur grundlegenden Anforderung, und zwar zu einer, die Marktueberwachungsbehoerden einsehen koennen.

Der Grund ist simpel. Wenn in einer weit verbreiteten Bibliothek eine Schwachstelle veroeffentlicht wird, zaehlt nur eine Frage: sind wir betroffen? Ohne Stueckliste kostet die Antwort Wochen manueller Archaeologie in Repositories und Build-Servern. Mit Stueckliste kostet sie eine Abfrage. Der CRA macht aus dieser operativen Realitaet eine Rechtspflicht — und wie bei den meisten Produktdatenpflichten geht es weit weniger darum, einmal ein Dokument zu schreiben, als darum, Daten ueber jedes Release hinweg ein Jahrzehnt lang richtig zu halten. Genau diese Disziplin verlangt der digitale Produktpass an anderer Stelle im EU-Produktrecht.

Das Wichtigste in Kuerze

Die SBOM-Pflicht steht in Anhang I Teil II des CRA, bei den Anforderungen an die Schwachstellenbehandlung. Sie gilt vollstaendig ab 11. Dezember 2027.
Die rechtliche Untergrenze ist bescheiden: ein gaengiges, maschinenlesbares Format, das mindestens die Abhaengigkeiten der obersten Ebene abdeckt, aktuell gehalten. Ein konkretes Format nennt die Verordnung nicht.
In der Praxis heisst das CycloneDX (OWASP, normiert als ECMA-424) oder SPDX (Linux Foundation, ISO/IEC 5962:2021). SWID-Tags (ISO/IEC 19770-2) sind eine Kennung fuer das Software-Asset-Management, kein vollstaendiges Abhaengigkeitsverzeichnis.
Es gibt keine Pflicht, die SBOM an Kunden zu veroeffentlichen. Sie ist der Marktueberwachung auf Verlangen vorzulegen und Teil der technischen Dokumentation nach Anhang VII.
Die technische Dokumentation ist den Behoerden mindestens zehn Jahre nach Inverkehrbringen zur Verfuegung zu halten — oder fuer den Unterstuetzungszeitraum, falls dieser laenger ist.
Die deutsche BSI TR-03183-2 geht deutlich ueber die CRA-Untergrenze hinaus: rekursive Aufloesung des gesamten Abhaengigkeitsbaums, SHA-512-Hashes, definierter Feldsatz. Sie ist kein zwingendes Recht, aber die konkreteste veroeffentlichte Referenz — und Einkaeufer berufen sich zunehmend darauf.
Eine SBOM, die nicht an eine konkrete Produktversion gebunden ist, beweist nichts. Versionieren statt Ueberschreiben ist der ganze Punkt.
Der CRA verlangt keine SBOM im digitalen Produktpass. Er verlangt Produktdaten auf Versionsebene, die ein Jahrzehnt ueberdauern — dasselbe Problem, geloest mit demselben Werkzeug.

Was eine SBOM tatsaechlich ist

Ohne das Akronym ist eine SBOM ein Bestandsverzeichnis mit Herkunftsnachweis. Fuer jede Komponente im ausgelieferten Produkt haelt sie mindestens fest, wie die Komponente heisst, welche Version sie hat und wer sie geliefert hat. Bessere Stuecklisten ergaenzen die Lizenz, einen kryptografischen Hash zur eindeutigen Identifikation und die Abhaengigkeitsbeziehungen — welche Komponente welche andere hereingezogen hat.

Der wichtigste Unterschied ist die Tiefe. Eine SBOM der obersten Ebene listet, was der eigene Code direkt deklariert: die zwoelf Bibliotheken in der Manifestdatei. Eine transitive SBOM loest auf, was diese zwoelf mitbringen, und was jene wiederum mitbringen, bis zu den Blaettern. Aus zwoelf deklarierten Abhaengigkeiten werden in realen Anwendungen routinemaessig mehrere Hundert tatsaechliche. Schwachstellen sitzen genauso wahrscheinlich vier Ebenen tief wie ganz oben — weshalb der Abstand zwischen der CRA-Untergrenze und einer brauchbaren SBOM nicht akademisch ist.

Der zweite Unterschied ist der Erzeugungszeitpunkt. Eine aus dem Quellcode erzeugte SBOM beschreibt, was die Entwicklung beabsichtigt hat. Eine aus dem Build-Ergebnis erzeugte SBOM beschreibt, was tatsaechlich ausgeliefert wurde — einschliesslich der Bestandteile, die das Build-System, das Basis-Container-Image oder das Binaerpaket eines Zulieferers eingebracht haben. Beide weichen haeufiger voneinander ab, als Teams erwarten, und nur die zweite ist ein Nachweis.

Was der CRA verlangt — und was nicht

Anhang I Teil II der Verordnung (EU) 2024/2847 beschreibt die Anforderungen an die Schwachstellenbehandlung, die ein Hersteller ueber den gesamten Unterstuetzungszeitraum erfuellen muss. Die erste davon ist die Stueckliste: Hersteller muessen die im Produkt enthaltenen Komponenten ermitteln und dokumentieren, unter anderem durch Erstellung einer Software-Stueckliste in einem gaengigen, maschinenlesbaren Format, die zumindest die Abhaengigkeiten der obersten Ebene abdeckt, und sie aktuell halten.

Drei Punkte dieses Satzes lohnen genaues Lesen.

„Gaengiges, maschinenlesbares Format.” Die Verordnung nennt bewusst kein Format. Das ist im EU-Produktrecht ueblich: der Rechtstext benennt die Eigenschaft, harmonisierte Normen liefern die technische Ausgestaltung. In der Praxis hat sich das Feld auf zwei Formate verdichtet, und beide sind vertretbar.

„Zumindest die Abhaengigkeiten der obersten Ebene.” Das ist eine Untergrenze, kein Ziel. Das Gesetz zwingt nicht zur Aufloesung des vollstaendigen transitiven Baums. Es hindert aber weder eine Behoerde noch eine Zertifizierungsstelle noch einen Grosskunden daran, mehr zu verlangen — und es macht eine SBOM ohne Tiefe nicht brauchbar fuer den Zweck, zu dem sie existiert. Behandeln Sie die Untergrenze als Compliance-Minimum und den transitiven Baum als operative Anforderung.

„Aktuell halten.” Die Pflicht ist fortlaufend und laeuft ueber den Unterstuetzungszeitraum. Eine einmal fuer die technische Akte erstellte und nie neu erzeugte Stueckliste weicht mit dem ersten Patch-Release von der Realitaet ab.

Was der CRA nicht verlangt, ist ebenso wichtig:

Keine Veroeffentlichungspflicht. Die SBOM oeffentlich zu machen ist eine kaufmaennische Entscheidung. Die Rechtspflicht lautet: der Marktueberwachung auf Verlangen vorlegen. Manche Branchen und grosse Einkaeufer verlangen sie vertraglich — das ist ein anderer Druck, kein rechtlicher.
Kein vorgeschriebenes Format und kein Profil. Kein CycloneDX-gegen-SPDX-Gebot, keine Mindestfeldliste in der Verordnung selbst.
Keine SBOM im Produktpass. Der CRA schafft keinen Pass, keinen Datentraeger und kein Register.

Formate: CycloneDX, SPDX und SWID

	CycloneDX	SPDX	SWID-Tags
Herkunft	OWASP	Linux Foundation	ISO/IEC
Norm	ECMA-424	ISO/IEC 5962:2021	ISO/IEC 19770-2
Konzipiert fuer	Anwendungssicherheit	Lizenz-Compliance und Herkunft	Software-Asset-Management
Typische Staerke	Schwachstellen-Workflows, CI/CD, VEX	Datei- und Snippet-Ebene, Einkauf	Identifikation installierter Software
Vollstaendiges Abhaengigkeitsverzeichnis	ja	ja	nicht der Zweck

CycloneDX stammt aus der Anwendungssicherheit und wurde von Beginn an fuer Sicherheitsanwendungen gebaut. Der praktische Vorteil ist das Oekosystem: es reicht ueber Hardware-, SaaS-, Machine-Learning- und Kryptografie-Stuecklisten hinaus und traegt VEX — Vulnerability Exploitability eXchange —, womit sich maschinenlesbar festhalten laesst, dass eine bekannte Schwachstelle in einer gelisteten Komponente im eigenen Produkt gar nicht ausnutzbar ist. Fuer einen Hersteller mit CRA-Pflichten zur Schwachstellenbehandlung ist die Aussage „vorhanden, aber nicht ausnutzbar, und hier ist der Grund” in maschinenlesbarer Form sehr viel eingesparte Arbeit wert.

SPDX kommt aus der Lizenz-Compliance und traegt dieses Erbe als Tiefe: es beschreibt Software bis auf einzelne Dateien und Codeabschnitte und ist die natuerliche Wahl, wenn Einkauf, Rechtspruefung und formale Dokumentation die Anforderung treiben.

SWID-Tags tauchen in fast jedem Formatvergleich und in mancher amtlichen Leitlinie auf, loesen aber ein anderes Problem: die Identifikation installierter Software auf einem System. Sie ersetzen kein Abhaengigkeitsverzeichnis.

Die ehrliche Antwort zur Wahl: beide fuehrenden Formate naehern sich an, Werkzeuge unterstuetzen beide, Konverter existieren. Nehmen Sie das Format, das Ihre bestehende Toolchain am zuverlaessigsten erzeugt, und standardisieren Sie darauf. Eine kaputte SBOM im „besseren” Format ist schlechter als eine korrekte in einem der beiden.

Die Datenfelder — drei Referenzpunkte

Der CRA gibt eine Untergrenze vor. Drei veroeffentlichte Dokumente sagen, was eine ernsthafte SBOM tatsaechlich enthaelt.

Die deutsche Referenz: BSI TR-03183-2

Das Bundesamt fuer Sicherheit in der Informationstechnik veroeffentlicht die Technische Richtlinie TR-03183: Cyber-Resilienz-Anforderungen an Hersteller und Produkte, Teil 2: Software-Stueckliste (SBOM). Sie ist kein zwingendes Recht, aber die konkreteste oeffentliche Spezifikation, die ausdruecklich gegen den CRA geschrieben wurde — und sie wird in deutschen Lieferantenfragebogen zunehmend zitiert. Version 2.1.0 erschien im August 2025.

Verlangt wird eine Serialisierung in JSON oder XML, in CycloneDX ab Version 1.6 oder SPDX ab Version 3.0.1. Die Felder fallen in drei Kategorien: erforderlich (immer), zusaetzlich (verpflichtend, sobald die zugrunde liegende Angabe existiert) und optional.

Erforderlich auf Dokumentebene:

Ersteller der SBOM — E-Mail-Adresse oder URL des Erzeugers
Zeitstempel im Format ISO 8601

Erforderlich je Komponente:

Name der Komponente
Version der Komponente
Ersteller der Komponente, also der Lieferant
Dateiname der Komponente
Abhaengigkeiten zu anderen Komponenten — rekursiv aufgeloest
Vertriebslizenzen
Hash der auslieferbaren Komponente, SHA-512
ob die Komponente ausfuehrbar ist, ob sie ein Archiv ist, ob sie strukturiert ist

Beachten Sie den Abstand zum CRA-Text. Die rekursive Aufloesung des gesamten Abhaengigkeitsbaums ist erheblich mehr Arbeit als die oberste Ebene, und die SHA-512-Anforderung zwingt dazu, die SBOM aus echten Build-Artefakten zu erzeugen statt aus einer Manifestdatei. Wer in den deutschen Markt liefert, plant besser gegen diese Referenz als gegen die Untergrenze der Verordnung.

Die US-Basislinie: NTIA-Mindestelemente

Die Minimum Elements for a Software Bill of Materials der NTIA von 2021 definierten sieben Basisfelder, auf die die meisten Werkzeuge bis heute zielen: Name des Lieferanten, Name der Komponente, Version, weitere eindeutige Kennungen, Abhaengigkeitsbeziehung, Urheber der SBOM-Daten und Zeitstempel. Die US-Leitlinien wurden seither ueberarbeitet — die CISA fuehrte eine oeffentliche Konsultation zu einem aktualisierten Satz von Mindestelementen durch, der Felder wie Komponenten-Hash, Lizenz und Erzeugungskontext ergaenzt. Wer bereits SBOMs fuer US-Bundeskunden erzeugt, liegt nahe an der CRA-Untergrenze — aber noch nicht bei der deutschen Referenz.

Die harmonisierten Normen, noch in Arbeit

Der Normungsauftrag der Kommission zum CRA wurde am 3. April 2025 von CEN, CENELEC und ETSI angenommen und umfasst ein Programm horizontaler und vertikaler Normen. Einschlaegig ist hier die horizontale Reihe EN 40000, insbesondere die Norm zur Schwachstellenbehandlung, in der die SBOM-Praxis festgeschrieben wird. Zum Redaktionszeitpunkt befinden sich diese Normen noch im Entwurfs- und Genehmigungsverfahren, und die Kommission hat eine Verschiebung der Liefertermine ins Gespraech gebracht.

Die praktische Folge: nicht auf die harmonisierte Norm warten. Ihr Inhalt entsteht gegen denselben Anhang-I-Text, und die operative Arbeit — den Build so einzurichten, dass er je Release eine SBOM ausgibt — aendert sich nicht danach, welche Feldliste sich durchsetzt. Warten kostet das Jahr an Release-Historie, das man sonst bereits haette.

Wo SBOMs in der Praxis scheitern

Von Hand erzeugt, einmalig

Der haeufigste Fehler ist eine Tabelle, die fuer die technische Akte zusammengestellt, nach JSON exportiert und nie wieder angefasst wird. Am Tag der Erstellung ist sie richtig, beim ersten Versionssprung einer Abhaengigkeit falsch. Die CRA-Pflicht lautet, die Stueckliste aktuell zu halten — eine veraltete SBOM ist deshalb keine Teilerfuellung, sondern ein dokumentierter Verstoss gegen eine fortlaufende Pflicht.

Nicht an eine Version gebunden

Eine SBOM ohne eindeutige Angabe, welches Produkt, welche Version und welchen Build sie beschreibt, beweist nichts. Wenn eine Behoerde fragt, ob die im Maerz 2028 ausgelieferten Einheiten eine verwundbare Bibliothek enthielten, brauchen Sie die Stueckliste dieses Builds, nicht die aktuelle. Das ist der haeufigste strukturelle Fehler — und ein Problem der Datenmodellierung, nicht der Sicherheit.

Aus dem Quellcode statt aus dem Artefakt

Manifestdateien beschreiben Absichten. Das ausgelieferte Artefakt enthaelt, was der Build produziert hat: das Basis-Image, die statisch gelinkte Bibliothek, das als Binaerpaket beigelegte Zulieferer-SDK. Nur aus dem Quellcode erzeugte SBOMs melden systematisch zu wenig — und die fehlenden Komponenten sind ueberproportional jene, die niemand patcht.

Fremd- und eingebettete Komponenten fehlen

Liefert ein Zulieferer ein Modul, sind dessen Komponenten in Ihrem Produkt. Dem CRA ist gleichgueltig, dass Sie sie nicht geschrieben haben. SBOMs von Lieferanten zu bekommen ist ein Beschaffungsproblem mit langer Vorlaufzeit — Vertraege muessen geaendert werden, und kleine Zulieferer haben oft gar keine Faehigkeit dazu. Damit sollte man am fruehesten anfangen.

Kein Ort zur Aufbewahrung

Eine SBOM je Release, zehn Jahre oder den Unterstuetzungszeitraum lang aufbewahrt, ueber Produktfamilien hinweg, ist ein versionierter Datenbestand, der Werkzeugwechsel, Repository-Umzuege und den Weggang desjenigen ueberstehen muss, der ihn eingerichtet hat. Ein Build-Artefakt in einem CI-System, das in drei Jahren ersetzt wird, ist keine Aufbewahrungsstrategie.

SBOM in den Release-Prozess bringen — fuenf Schritte

Automatisch aus dem Build erzeugen. Die SBOM-Erzeugung in die Pipeline-Stufe legen, die das auslieferbare Artefakt herstellt — so kann keine SBOM ohne Build und kein Build ohne SBOM existieren. Manuelle Erzeugung driftet immer.
Die SBOM an eine Identitaet binden. Produkt, Version, Build-Kennung, Zeitstempel. Das macht aus einer Datei einen Nachweis, und genau dieser Schritt wird am haeufigsten uebersprungen.
Tiefe und Format festlegen und aufschreiben. CycloneDX oder SPDX entscheiden, entscheiden ob transitiv aufgeloest wird (das sollte es), und die Entscheidung dokumentieren, damit sie sechs Release-Zyklen spaeter niemand stillschweigend aendert.
Die Anforderung in die Lieferkette schieben. Lieferantenvertraege so aendern, dass je gelieferter Version eine SBOM im gewaehlten Format verlangt wird. Mit den Lieferanten der Komponenten beginnen, die Sie nicht selbst pruefen koennen.
Dort ablegen, wo es in zehn Jahren noch lesbar ist. Versioniert, nach Produkt und Release indiziert, abrufbar ohne das urspruengliche Build-System. Die Aufbewahrung ist die Anforderung, die jedes Werkzeug ueberlebt, mit dem man sie erfuellt.

Das groessere Datenprogramm, in dem das steckt, behandelt unsere DPP-Implementierungs-Checkliste.

Was das fuer Produktdaten bedeutet

Die Grenze klar gezogen: der CRA setzt keine SBOM in einen digitalen Produktpass. Die Verordnung enthaelt keine Passpflicht, und keine Lesart macht aus einer Stueckliste ein oeffentliches Feld. Passpflichten kommen aus der Oekodesign-Verordnung und aus sektoralen Rechtsakten, die sie ausdruecklich anordnen.

Was beide Regime teilen, ist die Form. Beide verlangen Daten, die

an eine Version gebunden sind, nicht an eine Produktlinie. Die SBOM aendert sich mit jedem Release, genau wie Passdaten sich mit jeder Spezifikationsaenderung aendern. Systeme, die den aktuellen Datensatz ueberschreiben, koennen keine Frage zu einer vor drei Jahren verkauften Einheit beantworten.
von Grund auf maschinenlesbar sind. Kein PDF, das zufaellig eine Tabelle enthaelt, sondern ein strukturiertes Dokument, das ein anderes System ohne Menschen dazwischen verarbeiten kann.
ein Jahrzehnt aufbewahrt werden. Zehn Jahre technische Dokumentation nach dem CRA sind dieselbe Infrastrukturzusage wie langfristige Passverfuegbarkeit nach der Oekodesign-Verordnung.
ueber Kanaele hinweg konsistent sind. Das Ende des Unterstuetzungszeitraums, die Kontaktstelle fuer Schwachstellen und die Angaben zu Aktualisierungen muessen im eigenen Shop, beim Haendler und in der Dokumentation dasselbe sagen.

Fuer Elektronik verstaerkt sich das Argument. Dasselbe Produkt liegt gleichzeitig im Anwendungsbereich der Oekodesign-Verordnung, der RoHS-Richtlinie, der WEEE-Richtlinie und des CRA. Wer Stoffdaten in einem System, Reparierbarkeitsdaten in einem zweiten und Softwarekomponentendaten in einem dritten fuehrt, unterhaelt vier Register ueber ein Produkt. Ausgangspunkt fuer die Zusammenfuehrung ist unsere vollstaendige Liste der DPP-Datenanforderungen, und die zugrunde liegende Argumentation steht in DPP und PIM.

Eine ehrliche Anmerkung dazu, wo eine Pass-Plattform aufhoert: myDPP erzeugt keine SBOMs, scannt weder Code noch Container, gleicht keine Stueckliste gegen einen Build ab, fuehrt keine Schwachstellenanalyse durch und bewertet keine CRA-Konformitaet. Das gehoert in Ihre Entwicklungs-Toolchain und, wo gefordert, zu einer notifizierten Stelle. Was eine Pass-Plattform tut: versionierte Produktdaten speichern, sie ueber Jahre abrufbar halten und die Teile veroeffentlichen, die oeffentlich sein sollen. Die Verantwortung fuer die Konformitaet bleibt beim Hersteller.

Zeitplan

Datum	Was passiert
10. Dezember 2024	Verordnung (EU) 2024/2847 tritt in Kraft
3. April 2025	CEN, CENELEC und ETSI nehmen den Normungsauftrag an
11. Juni 2026	Vorschriften zu notifizierten Stellen gelten
11. September 2026	Meldepflichten gelten — auch fuer bereits in Verkehr befindliche Produkte
11. Dezember 2027	Vollstaendige Anwendung — die SBOM-Anforderung aus Anhang I wird verbindlich

Die Meldepflicht kommt mehr als ein Jahr vor der SBOM-Pflicht, und diese Reihenfolge ist lehrreich. Ab September 2026 kann es sein, dass Sie eine aktiv ausgenutzte Schwachstelle binnen 24 Stunden melden muessen. Die Frage „welche unserer Produkte enthalten diese Komponente” innerhalb dieses Fensters zu beantworten ist genau das Problem, fuer das eine SBOM existiert — womit die praktische Frist deutlich vor der rechtlichen liegt.

Haeufige Fragen

Muss ich meine SBOM veroeffentlichen?

Nein. Der CRA verpflichtet dazu, sie zu erstellen, aktuell zu halten und der Marktueberwachung auf Verlangen vorzulegen. Sie wird Teil der technischen Dokumentation. Die Veroeffentlichung gegenueber Kunden ist eine kaufmaennische Entscheidung — und zunehmend eine vertragliche Forderung grosser Einkaeufer, was von der Rechtspflicht zu trennen ist.

Reicht eine Liste der obersten Ebene?

Sie erfuellt den Wortlaut von Anhang I Teil II. Sie erfuellt nicht die BSI TR-03183-2, die eine rekursive Aufloesung des Abhaengigkeitsbaums verlangt, und sie beantwortet nicht die Frage, die Sie tatsaechlich beantworten muessen, wenn eine Schwachstelle vier Ebenen tief auftaucht. Oberste Ebene ist die Untergrenze, transitiv das Ziel.

CycloneDX oder SPDX?

Beides ist unter dem CRA vertretbar, der kein Format nennt. CycloneDX hat das staerkere Sicherheits-Oekosystem und traegt VEX; SPDX hat mehr Tiefe fuer Lizenz- und Herkunftsarbeit. Die BSI TR-03183-2 akzeptiert CycloneDX ab 1.6 oder SPDX ab 3.0.1. Ausschlaggebend sollte sein, was Ihre bestehende Toolchain zuverlaessig erzeugt.

Wie lange muss ich SBOMs aufbewahren?

Die SBOM ist Teil der technischen Dokumentation, die der Marktueberwachung mindestens zehn Jahre nach Inverkehrbringen des Produkts zur Verfuegung zu halten ist — oder fuer die Dauer des Unterstuetzungszeitraums, falls dieser laenger ist. Da mit jedem Release eine neue SBOM entsteht, ist das ein versioniertes Archiv, keine einzelne Datei.

Gehoert eine SBOM in den digitalen Produktpass?

Rechtlich nicht. Der CRA schafft keine Passpflicht, und kein geltender Pass-Rechtsakt verlangt eine Stueckliste als Datenfeld. Die Ueberschneidung liegt in der Infrastruktur: beide brauchen maschinenlesbare Produktdaten auf Versionsebene, ein Jahrzehnt aufbewahrt und ueber eine stabile Kennung erreichbar.

Weiterlesen

Quellen

Verordnung (EU) 2024/2847 — Cyber Resilience Act — EUR-Lex
Der Cyber Resilience Act — Zusammenfassung des Rechtstextes — Europaeische Kommission
BSI TR-03183-2: Software Bill of Materials (SBOM) — Bundesamt fuer Sicherheit in der Informationstechnik
CycloneDX — ECMA-424 — OWASP
SPDX — ISO/IEC 5962:2021 — Linux Foundation
Minimum Elements for a Software Bill of Materials — CISA