Das Wichtigste in Kürze (Stand: Oktober 2026)
- Eine SBOM (Software-Stückliste) führt für ein Release alle Komponenten einer Software mit Hersteller, Name, Version und Abhängigkeiten in einem maschinenlesbaren Format auf.
- Der Cyber Resilience Act, Verordnung (EU) 2024/2847, verpflichtet Hersteller von Produkten mit digitalen Elementen ab dem 11. Dezember 2027 zu einer SBOM, die zumindest die obersten Abhängigkeiten zeigt (Anhang I Teil II Nummer 1).
- Veröffentlichen müssen Hersteller die SBOM nicht (Erwägungsgrund 77); als Teil der technischen Dokumentation ist sie mindestens zehn Jahre oder für den Unterstützungszeitraum aufzubewahren, je nachdem, welcher Zeitraum länger ist.
- Der CRA schreibt kein Format vor; BSI TR-03183-2 (Version 2.1.0) verlangt CycloneDX ab Version 1.6 oder SPDX ab Version 3.0.1, jeweils als JSON oder XML.
- Wer Software nur einsetzt, ist aus dem CRA nicht zur SBOM verpflichtet, kann sie aber von seinen Lieferanten anfordern.
Was ist eine SBOM, und was steht darin?
Eine SBOM ist die maschinenlesbare Liste der Komponenten, aus denen ein bestimmtes Release einer Software besteht. Sie führt jede eingebundene Komponente mit Hersteller, Name, Version und Abhängigkeiten auf, also eigene Module ebenso wie Open-Source-Bibliotheken und zugekaufte Bestandteile. Der Cyber Resilience Act definiert die Software-Stückliste in Artikel 3 Nummer 39 als formale Aufzeichnung der Einzelheiten und Lieferkettenbeziehungen der Komponenten, die in den Softwareelementen eines Produkts enthalten sind.
Pflichtfelder nach BSI TR-03183-2
Welche Felder genau hineingehören, legt der CRA selbst nicht fest. Konkreter ist die Technische Richtlinie BSI TR-03183-2 (Version 2.1.0 vom 20. August 2025). Sie verlangt mindestens:
| Ebene | Pflichtfeld nach BSI TR-03183-2 | Wozu es dient |
|---|---|---|
| SBOM | Ersteller (E-Mail-Adresse, ersatzweise URL) | Ansprechpartner für Rückfragen zur Stückliste |
| SBOM | Zeitstempel der Erstellung | Zuordnung zum Build und zum Release |
| Komponente | Ersteller der Komponente | Wer die Komponente entwickelt und pflegt |
| Komponente | Name und Version | Abgleich mit Schwachstellendatenbanken |
| Komponente | Dateiname | Wiederfinden im ausgelieferten Paket |
| Komponente | Abhängigkeiten, mit Angabe zur Vollständigkeit | Nachverfolgung transitiver Risiken |
| Komponente | Lizenzen, unter denen die Komponente weitergegeben wird | Lizenz-Compliance |
| Komponente | Hashwert der auslieferbaren Komponente (SHA-512) | Nachweis, dass genau diese Datei gemeint ist |
| Komponente | Eigenschaften: ausführbar, Archiv, strukturiert | Einordnung der Datei bei der Analyse |
Sofern vorhanden, kommen weitere Angaben hinzu, etwa die URI des Quellcodes und eindeutige Kennungen wie Package URL (purl) oder CPE, über die sich Komponenten in Schwachstellendatenbanken nachschlagen lassen.
Ist eine SBOM Pflicht?
Für Hersteller von Produkten mit digitalen Elementen ja, ab dem 11. Dezember 2027. Artikel 13 Absatz 8 der Verordnung (EU) 2024/2847 verpflichtet Hersteller, Schwachstellen ihres Produkts einschließlich seiner Komponenten nach Anhang I Teil II zu behandeln. Dessen Nummer 1 verlangt, Schwachstellen und Komponenten zu ermitteln und zu dokumentieren, unter anderem durch eine Software-Stückliste in einem gängigen maschinenlesbaren Format, aus der zumindest die obersten Abhängigkeiten hervorgehen. Anhang VII Nummer 2 Buchstabe b führt die Software-Stückliste zudem als Teil der technischen Dokumentation auf. Auch das BSI bezeichnet die SBOM in der TR-03183-2 als Pflicht nach dem CRA. Wie sich diese Pflicht in die übrige CRA-Umsetzung einfügt, zeigt der CRA-Leitfaden.
Drei Grenzen der SBOM-Pflicht
- Adressat ist der Hersteller. Wer Software nur einsetzt, ist aus dem CRA nicht zur SBOM verpflichtet. Er hat aber ein berechtigtes Interesse, sie von seinen Lieferanten zu erhalten; wie sich Hersteller- und Betreiberpflichten unterscheiden, zeigt der Vergleich CRA vs. NIS2.
- Die Pflicht wirkt nicht rückwirkend. Nach Artikel 69 Absatz 2 unterliegen Produkte, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden, den Anforderungen nur, wenn sie danach wesentlich geändert werden. Die Ausnahme in Absatz 3 betrifft allein die Meldepflichten nach Artikel 14, die bereits seit dem 11. September 2026 gelten.
- Gefordert ist ein Minimum. Der Verordnungstext verlangt die obersten Abhängigkeiten. Eine Stückliste, die nur diese Ebene zeigt, hilft bei einer Schwachstelle tief im Abhängigkeitsbaum jedoch wenig.
Veröffentlichung: keine Pflicht, aber Vorlage auf Verlangen
Erwägungsgrund 77 stellt klar, dass Hersteller nicht verpflichtet sein sollten, die Software-Stückliste zu veröffentlichen. Sie gehört nach Anhang VII Nummer 2 Buchstabe b zur technischen Dokumentation und ist der Marktüberwachungsbehörde nach Anhang VII Nummer 8 auf begründetes Verlangen vorzulegen, soweit diese damit die Einhaltung der Anforderungen prüft. Stellt der Hersteller die SBOM seinen Nutzern freiwillig bereit, muss er nach Anhang II Nummer 9 angeben, wo sie abrufbar ist.
Unionsweite Abhängigkeitsbewertung
Zusätzlich kann die Gruppe zur administrativen Zusammenarbeit (ADCO) nach Artikel 13 Absatz 25 für bestimmte Produktkategorien eine unionsweite Bewertung der Abhängigkeit von Softwarekomponenten beschließen; dafür können die Marktüberwachungsbehörden die Stücklisten bei den Herstellern anfordern.
Formate: SPDX, CycloneDX und die Vorgaben der BSI TR-03183-2
Der CRA nennt kein bestimmtes Format, sondern verlangt ein gängiges maschinenlesbares. Artikel 13 Absatz 24 ermächtigt die Kommission, Format und Elemente der Stückliste durch Durchführungsrechtsakte festzulegen. Verbreitet sind zwei Formate, SPDX und CycloneDX; beide akzeptiert auch die BSI TR-03183-2.
| Aspekt | Mindestanforderung im CRA | BSI TR-03183-2 (Version 2.1.0) |
|---|---|---|
| Rechtsnatur | Verordnung, unmittelbar verbindlich | Technische Richtlinie des BSI, kein Rechtsakt |
| Format | gängig und maschinenlesbar | CycloneDX ab Version 1.6 oder SPDX ab Version 3.0.1, als JSON oder XML |
| Tiefe | zumindest die obersten Abhängigkeiten | rekursiv für alle Komponenten im Lieferumfang, bis einschließlich der ersten Komponente außerhalb davon |
| Felder | nicht im Einzelnen festgelegt | Pflicht- und Zusatzfelder für SBOM und Komponente |
Wer sich an der TR orientiert, liegt über dem gesetzlichen Minimum. Das ist eine bewusste Entscheidung, keine Pflicht, spart aber Nacharbeit, falls die Kommission Format und Elemente später verbindlich festlegt.
Wie erstellen Sie eine SBOM in 6 Schritten?
Eine SBOM entsteht in sechs Schritten, von der Erzeugung im Build bis zur benannten Zuständigkeit für neue Schwachstellen:
- Im Build erzeugen. Die Stückliste wird automatisch aus dem Build-Prozess erzeugt, nicht nachträglich von Hand gepflegt. BSI TR-03183-2 verlangt dieselben Informationen, die während des Builds verfügbar sind.
- Je Release versionieren. Jede ausgelieferte Version erhält ihre eigene SBOM, die zusammen mit dem Artefakt archiviert wird. Als Teil der technischen Dokumentation ist sie nach Artikel 13 Absatz 13 mindestens zehn Jahre oder für die Dauer des Unterstützungszeitraums aufzubewahren, je nachdem, welcher Zeitraum länger ist.
- Gegen Schwachstellendaten abgleichen. Die Komponentenliste wird laufend mit Schwachstellendatenbanken abgeglichen. Erst dieser Schritt macht aus der Stückliste ein Werkzeug des Schwachstellenmanagements.
- Ausnutzbarkeit bewerten. Nicht jede gemeldete Schwachstelle in einer Komponente ist im Produkt ausnutzbar. Diese Bewertung lässt sich in einem VEX-Dokument (Vulnerability Exploitability eXchange) festhalten und an Kunden weitergeben.
- Zulieferer einbeziehen. Für zugekaufte Komponenten werden SBOMs vertraglich angefordert. Artikel 13 Absatz 5 verlangt von Herstellern ohnehin die gebotene Sorgfalt bei der Integration von Komponenten Dritter.
- Zuständigkeit festlegen. Jemand muss reagieren, wenn eine neue Schwachstelle eine gelistete Komponente betrifft. Ohne benannte Verantwortung bleibt die SBOM ein Archivdokument.
Welche Reihenfolge die übrigen CRA-Pflichten nahelegen, ordnet der Beitrag CRA-Compliance umsetzen.
SBOM, Asset-Inventar und Schwachstellenmanagement: wer was nutzt
Die SBOM beschreibt den Inhalt eines Produkts, das Asset-Inventar beschreibt, was eine Organisation betreibt. Beide treffen sich beim Schwachstellenmanagement: Der Hersteller nutzt die Stückliste, um betroffene Releases zu finden; der Betreiber nutzt die Stücklisten seiner Lieferanten, um zu erkennen, welche eingesetzten Systeme betroffen sind. Für Betreiber ist die SBOM deshalb vor allem ein Instrument der Lieferkettensicherheit, das sie in Ausschreibungen und Verträgen anfordern können, und eine Ergänzung zum IT-Asset-Management.
Rizzqo und die SBOM: der Arbeitsrahmen
Der Cyber Resilience Act ist in Rizzqo als Anforderungskatalog hinterlegt. Build-Umgebung, Repositorien, Softwarebibliotheken und Zulieferer lassen sich als unterstützende Assets mit Kategorie, Unterkategorie und zuweisbarem Verantwortlichen modellieren und untereinander verknüpfen. Anforderungen erscheinen über Kategorie und Unterkategorie an den passenden Assets. Ihre Beantwortung wird mit Namen und Zeitstempel abgeschlossen, und der Erfüllungsgrad rechnet sich aus den abgeschlossenen Antworten.