SBOM unter CRA: Praktischer Leitfaden für Hersteller und Integratoren

Der Cyber Resilience Act (CRA) verlangt von Herstellern digitaler Produkte eine aktuelle Software Bill of Materials – eine vollständige Liste der Komponenten, Abhängigkeiten und Versionen, die in einem Produkt stecken. Was in der Diskussion oft abstrakt klingt, hat in der Praxis ganz konkrete Anforderungen: ein Format, eine Werkzeugkette, einen Prozess für Schwachstellen­meldungen und eine Schnittstelle zur Konformitäts­bewertung. Wer als Hersteller oder Integrator 2026 mit CRA-pflichtigen Produkten arbeitet, sollte jetzt mit dem Aufbau beginnen – die zweite Anwendungsstufe greift im Dezember 2027, bis dahin muss die SBOM-Praxis stehen.

Der Beitrag baut auf dem CRA-Überblick und dem Beitrag zu Open-Source-Stewards auf und führt operativ in SBOM, VEX und die praktische Umsetzung. Stand: 22. August 2026.

Warum CRA und SBOM 2026 zusammenkommen

Der CRA ist seit Anfang 2025 in Kraft, in Anwendung tritt er in drei Stufen. Ab dem 11. September 2026 beginnen die ersten Meldepflichten für aktive Produkte, ab dem 11. Dezember 2027 gilt die volle Anwendbarkeit – einschließlich der Pflicht für kritische Produkte nach Anhang IV. Die SBOM ist dabei nicht eine Nebenpflicht, sondern Kernstück der technischen Dokumentation: wer eine aktuelle SBOM hat, kann die meisten anderen CRA-Pflichten aus ihr ableiten.

Was die Sache dringend macht: die SBOM ist nicht nur ein Compliance-Dokument, sondern operative Grundlage der Schwachstellen­bearbeitung. Wer eine Sicherheits­lücke in einer Bibliothek erkennt, muss innerhalb kürzester Zeit wissen, welche Produkte diese Bibliothek verwenden – anders lässt sich die CRA-Pflicht zur unverzüglichen Patch­bereit­stellung nicht erfüllen. Ohne SBOM ist das ein Blindflug.

In der Mandatspraxis sehe ich regelmäßig Hersteller, die zum CRA-Stichtag ohne SBOM-Struktur dastehen und jetzt mit Hochdruck aufsetzen müssen. Wer den Aufbau strukturiert angeht, hat bis zum 11. Dezember 2027 noch ein knappes Jahr Zeit – wer hier zuwartet, wird die Pflicht nicht fristgerecht erfüllen.

Was eine SBOM ist – und was nicht

Eine SBOM ist eine maschinenlesbare Liste der Software-Komponenten, die in einem Produkt steckt. Sie enthält im Idealfall den Namen der Komponente, die Version, den Lieferanten, einen Identifikator (etwa einen PURL oder CPE), die Lizenz und die Beziehung zu anderen Komponenten („depends on“, „contains“, „build dependency“). Was sie nicht enthält: den Quellcode, Sicherheits­informationen oder eine Bewertung der Komponenten. Dafür gibt es andere Formate, allen voran VEX.

Eine gute SBOM folgt den Mindest­elementen, die die US-Handels­behörde NTIA in einer Vereinbarung von 2019 festgelegt hat: Supplier (Anbieter der Komponente), Component Name, Version of the Component, Other Unique Identifiers, Dependency Relationship, Author of SBOM Data, Timestamp. Wer diese sechs Felder pro Komponente befüllt, ist formal CRA-kompatibel – aber meistens nicht praktisch ausreichend.

Wer eine SBOM aufsetzt, sollte sich bewusst sein, dass sie kein Audit-Dokument ist, das einmal erstellt und dann vergessen wird. SBOMs altern, weil sich Komponenten weiterentwickeln, neue Sicherheits­lücken bekannt werden und Versionen sich ändern. Eine SBOM ohne Datum und ohne Build-Identifier ist Wertstoff für den ersten Audit und Ramsch für den zweiten. Die CRA verlangt deshalb eineaktuelle SBOM – und aktuell heißt, dass das Erzeugungs­datum mit dokumentiert sein muss.

Die Pflicht nach CRA: Anhang I und Artikel 13

Anhang I des CRA listet die Anforderungen an die technische Dokumentation auf. Unter Punkt 2 ist von einer „Liste der Bestandteile des Produkts mit digitalen Elementen“ die Rede, die der SBOM entspricht. Die Formulierung ist offen – der Verordnungstext schreibt weder ein konkretes Format noch eine bestimmte Detail­tiefe vor. Das überlässt die Konkretisierung den Herstellern und den harmonisierten Standards, an denen CEN-CENELEC derzeit arbeitet.

Artikel 13 ergänzt die Pflicht zur Konformitäts­bewertung. Wer ein „wichtiges“ Produkt nach Anhang III in Verkehr bringt, muss eine Konformitäts­bewertung durchlaufen, deren Verfahren und Inhalt sich nach der Risikoklasse richten. Für die meisten Produkte reicht die Selbsterklärung durch den Hersteller; bei kritischen Produkten nach Anhang IV ist eine notifizierte Stelle erforderlich. Die SBOM gehört zu den Dokumentations­anforderungen, die bei der Konformitäts­bewertung vorgelegt werden müssen.

Was in der Praxis oft übersehen wird: die SBOM ist nicht nur ein internes Dokument, sondern muss auch den Behörden auf Verlangen zur Verfügung gestellt werden können. Wer die SBOM vor der Konformitäts­bewertung zusammenstellt, sollte deshalb darauf achten, dass sie maschinen­lesbar und mit einem Standard­werkzeug auswertbar ist. Eine hand­geschriebene Excel-Tabelle reicht formal nicht.

Was die Übergangs­regeln angeht: SBOM-Pflichten greifen grundsätzlich ab der jeweiligen Anwendungs­stufe des CRA. Wer ein Produkt vor dem 11. September 2025 in den Verkehr gebracht hat, fällt unter die erste Anwendungs­stufe und muss ab dann Meldungen zu aktiv ausgenutzten Schwachstellen machen, aber keine SBOM nachreichen. Wer ab dem 11. September 2026 ein neues Produkt in den Verkehr bringt, fällt voll unter die CRA-Pflichten einschließlich SBOM.

Die drei Formate: SPDX, CycloneDX, SWID

In der Praxis haben sich drei SBOM-Formate etabliert. SPDX wurde von der Linux Foundation entwickelt und ist heute der De-facto-Standard der Industrie – nahezu jede große Open-Source-Community kann SPDX-SBOMs erzeugen, und die meisten kommerziellen SCA-Tools (Software Composition Analysis) unterstützen es. SPDX-SBOMs werden als JSON, YAML oder Tag-Value ausgeliefert und sind über das Format gut dokumentiert.

CycloneDX ist aus dem OWASP-Umfeld hervorgegangen und wird besonders in sicherheits­kritischen Branchen und im Behörden­einsatz geschätzt. Das Format legt besonderen Wert auf die Eignung für Vulnerability Management – die Einbindung von VEX ist nativ vorgesehen. CycloneDX-SBOMs werden typischerweise als JSON ausgetauscht und sind kompakter als SPDX.

SWID (Software Identification) wurde im NIST entwickelt und ist besonders in Behörden­umgebungen verbreitet. SWID-Tags sind XML-basiert und werden oft als Ergänzung zu anderen Datenquellen genutzt – etwa für Lizenz­nachweise oder Patch-Identifikation. In der privaten Wirtschaft ist SWID weniger verbreitet als SPDX oder CycloneDX.

Welches Format die richtige Wahl ist, hängt von der Empfänger­struktur ab. Wer unternehmens­intern SBOMs erstellt, sollte das Format wählen, das die eigene Werkzeug­kette am besten unterstützt. Wer SBOMs an Aufsichts­behörden oder Kunden weitergeben muss, sollte das Format wählen, das diese erwarten – und sich auf mehrere Empfänger einstellen, da der CRA selbst kein Format vorschreibt.

In der Mandatspraxis hat sich bewährt, das SBOM-Format nicht in der Konformitäts­bewertung festzulegen, sondern in einer eigenen technischen Entscheidung zu dokumentieren. Wer die Wahl des Formats begründet und die Konvertierung zu einem anderen Format unterstützt, ist auch für künftige Wechsel gerüstet – etwa wenn die EU in einer delegierten Rechtsakte ein konkretes Format verpflichtend macht.

VEX – Schwachstellen zur SBOM dazu

Eine SBOM sagt, welche Komponenten in einem Produkt stecken. Sie sagt nicht, welche davon angreifbar sind. Diese Lücke schließt VEX (Vulnerability Exploitability eXchange). VEX ist ein maschinen­lesbares Format, das zu einer Sicherheits­lücke mitteilt, ob ein bestimmtes Produkt tatsächlich betroffen ist und welche Maßnahmen der Hersteller empfiehlt. VEX wurde ursprünglich von der Cybersecurity-Infrastruktur­behörde CISA entwickelt und wird heute in CycloneDX und SPDX eingebettet.

Für die CRA-Praxis ist VEX wichtig, weil die Pflicht zur Meldung aktiv ausgenutzter Schwachstellen nicht allein durch eine SBOM erfüllt wird – die SBOM listet die Komponenten, die CVE-Liste listet die Schwachstellen, und VEX verbindet beide. Wer eine kritische Schwachstelle in Log4j bekannt geben muss, hat mit einer SBOM allein nicht dokumentiert, ob das eigene Produkt betroffen ist. VEX schließt die Lücke.

In der Praxis empfehle ich, VEX-Sicherheits­meldungen direkt in den SBOM-Erstellungs­prozess zu integrieren. Wer eine SCA-Lösung (Software Composition Analysis) nutzt, kann aus dem Vulnerability-Feed automatisch VEX-Meldungen für die eigenen Produkte erzeugen. Bei bekanntem CVE wird ohnehin erwartet, dass man innerhalb von Stunden reagieren kann – wer die VEX-Pipeline nicht im Griff hat, verliert in der Krise Zeit.

Praktische Toolchain und Automation

Wer SBOMs erstellt, kommt an einer Werkzeugkette nicht vorbei. Drei Bereiche verdienen Beachtung: Erzeugung, Versionsverwaltung und Verteilung. Die Erzeugung läuft meistens beim Build-Prozess – moderne CI/CD-Pipelines integrieren SCA-Tools, die beim Kompilieren die Komponenten­liste generieren. Bekannte SCA-Lösungen sind unter anderem Syft, CycloneDX-Server-Module, FOSSA, Snyk Open Source und Mend (ehemals WhiteSource). Für kleinere Unternehmen reichen oft die SCA-Funktionen der genutzten Programmiersprachen – npm für JavaScript, Gradle für Java, Cargo für Rust.

Die Versionsverwaltung der SBOM ist ein kritischer Punkt. Wer die SBOM nur als Snapshot im Build-Output ablegt, hat morgen eine veraltete SBOM und übermorgen eine zweite SBOM für eine andere Version. Bewährt hat sich die Ablage im Artefakt-Repository neben dem Build-Artefakt selbst – mit gleichen Versionen und gleichen Hashes. Wer eine SBOM aus dem Repository abruft, soll sicher sein können, dass sie zur spezifischen Produkt­version gehört.

Die Verteilung der SBOM an Kunden und Behörden ist die dritte Sache, die in der Praxis schiefgeht. Wer die SBOM an einem versteckten Punkt im Webauftritt ablegt, wird Kunden und Aufsichts­behörden gleichermaßen frustrieren. Bewährt hat sich die Bereitstellung über ein CycloneDX SBOM-as-a-Service-Portal oder über direkten Link in der Produktdokumentation. Der CRA verlangt die Bereitstellung für einen Zeitraum von fünf Jahren nach Markteinführung – wer das nicht in der eigenen Architektur abgebildet hat, bekommt spätestens bei einer Rückruf­aktion Probleme.

Was die Werkzeugauswahl angeht: für jeden Reifegrad existieren passende Lösungen. Open-Source-Tools wie Dependency-Track und Syft decken die Grundbedürfnisse eines kleinen Herstellers ab; kommerzielle SCA-Tools von Snyk, Mend, FOSSA oder Sonatype ergänzen für mittelgroße und große Hersteller. Wer mit mehreren Programmiersprachen arbeitet, sollte darauf achten, dass das gewählte Tool alle Sprachen unterstützt, die im Unternehmen verwendet werden.

Schnittstellen zu NIS2, LkSG und DSGVO

Die SBOM hat im Compliance-Ökosystem eine wichtige Brücken­funktion. Wer als Hersteller schon eine SBOM hat, kann die gleichen Daten für andere Compliance-Pflichten verwenden: für die NIS2-Lieferketten­sorgfalt gegenüber Geschäfts­kunden im KRITIS-Bereich, für die DSGVO-Sicherheits­dokumentation nach Art. 32, und für die Lieferanten­bewertung im LkSG. Wer zusätzlich von NIS2-Schulungen betroffen ist, kann die SBOM-Daten als Schulungsmaterial verwenden.

Was die Schnittstelle zu NIS2 angeht: wer als IKT-Dienstleister einer NIS2-regulierten Stelle SBOMs zur Verfügung stellt, erfüllt zugleich die Anforderung des NIS2-Lieferketten­sicherheit. Wer umgekehrt als NIS2-Betroffener SBOMs von Lieferanten einfordert, kann daraus das eigene IKT-Risiko­inventar aktuell halten. Die SBOM wird damit zum Bindeglied zwischen der NIS2-Lieferketten­pflicht und der CRA-Produkt­verantwortung.

Schnittstelle zur DSGVO: wer eine SBOM hat, kann die Liste der verarbeiteten Bibliotheken an seine Datenschutz­dokumentation anbinden. In der Praxis heißt das: welche Personenbezugsdaten fließen durch welche Bibliothek, ist oft nur über die SBOM präzise dokumentierbar. Wer das nicht verknüpft, hat im Audit zwei Dokumente, die auseinander­laufen.

Schnittstelle zur Lieferanten­sorgfalt: das Lieferketten­sorgfalts­pflichtengesetz (LkSG) verlangt eine Bewertung der Lieferanten hinsichtlich Menschenrechts- und Umwelt­risiken. Die SBOM zeigt, welche Software-Komponenten von welchen Lieferanten stammen – und liefert damit eine Datenquelle, die auch für die Lieferanten­risiko­analyse genutzt werden kann.

Konformitätsbewertung und Bußgelder

Die Bußgelder des CRA sind empfindlich: bis 15 Millionen Euro oder 2,5 Prozent des Weltumsatzes – je nachdem, welcher Betrag höher ist. Was die genauen Anforderungen an die Konformitäts­bewertung angeht, hängt die Pflicht von der Risikoklasse des Produkts ab. Für die meisten Standardprodukte reicht die Selbsterklärung des Herstellers; für wichtige Produkte nach Anhang III ist die Selbsterklärung weiterhin möglich, muss aber von einer benannten, mit der Konformitäts­bewertung beauftragten Person abgezeichnet sein; für kritische Produkte nach Anhang IV ist eine Drittstellen-Prüfung durch eine notifizierte Stelle erforderlich.

Was in der Praxis entscheidend ist: die SBOM ist ein zentraler Bestandteil der Konformitäts­bewertungs­dokumentation. Wer die SBOM nicht aktualisiert, hat nicht nur eine inhaltliche Lücke, sondern auch einen formalen Mangel im Konformitäts­bewertungs­verfahren. Bei einer Aufsichts­prüfung kann der Standpunkt „unsere SBOM ist veraltet“ nicht ausreichen – die Verantwortung liegt beim Hersteller, eine aktuelle SBOM zu führen.

Die Schwachstellen­meldungen nach Art. 14 CRA sind unabhängig von der SBOM-Pflicht zu betrachten. Wer eine aktiv ausgenutzte Schwachstelle hat, muss das binnen 24 Stunden an ENISA melden; einzelne Schwachstellen müssen innerhalb angemessener Frist gepatcht werden. Wer diese Fristen wegen einer unzureichenden SBOM nicht einhalten kann, hat ein doppeltes Problem.

Praktischer Aufbau in acht Schritten

Wer heute beginnt, kann mit acht Schritten eine belastbare CRA-SBOM-Praxis aufsetzen.

Erstens: Bestandsaufnahme der eigenen Produkte. Welche Produkte fallen unter den CRA, welche unter Anhang III, welche unter Anhang IV. Wer diese Frage nicht beantworten kann, hat mit der SBOM-Pflicht noch nicht angefangen.

Drittens: SCA-Tool auswählen und in die CI/CD integrieren. Die SBOM-Generierung muss automatisch beim Build laufen, nicht manuell bei Audit-Vorbereitung.

Viertens: Format festlegen und Begründung dokumentieren. SPDX, CycloneDX oder SWID – egal welches Format, die Entscheidung gehört in die Konformitäts­dokumentation.

Fünftens: Speicherort definieren. SBOM neben Build-Artefakt im Artefakt-Repository; Versionierung mit Hash und Datum.

Sechstens: VEX-Pipeline einrichten. Bei bekanntem CVE automatisch prüfen, ob das eigene Produkt betroffen ist; gegebenenfalls VEX-Meldung erzeugen.

Siebtens: Bereitstellung. SBOM für Kunden und Behörden zugänglich machen – Webauftritt, Kundenportal oder direkter Download.

Achtens: Routine. Schwachstellen-Feeds täglich prüfen, SBOM quartalsweise validieren, Werkzeug-Updates zeitnah einspielen. Wer das einmalig macht, verliert nach zwei Quartalen den Anschluss.

Einordnung in die Compliance-Architektur

Die SBOM ist im Compliance-Gefüge eines modernen Software-Herstellers ein Knotenpunkt, kein Zusatzdokument. Sie bedient die CRA-Pflicht, sie versorgt die NIS2-Lieferketten­sorgfalt der Kunden mit Daten, sie unterstützt die DSGVO-Sicherheits­dokumentation, und sie ist die operative Basis für Schwachstellen­management. Wer die SBOM aufbaut, integriert damit mehrere Compliance-Bereiche auf einer einzigen Datenbasis – das ist mehr Wert als jede einzelne Pflicht.

In den kommenden zwei Jahren werden harmonisierte Standards die Konkretisierung der CRA-Pflichten mit Leben füllen. Wer jetzt aufsetzt, kann in den Übergangs­regelungen erfahren, ob die eigenen Strukturen tragfähig sind – und sie anpassen, bevor die Pflicht operativ wird.

Fazit

Die SBOM unter CRA ist eine operative Pflicht, die ab der zweiten Anwendungs­stufe am 11. Dezember 2027 für alle neuen Produkte greift. Wer sie bis dahin nicht aufgesetzt hat, fängt zu spät an – und der Aufbau dauert typischerweise sechs bis neun Monate, wenn alle Bestandteile zusammenkommen.

Acht Bausteine entscheiden: Bestand der CRA-Produkte, Werkzeug­auswahl, Format­wahl, Speicherort, VEX-Pipeline, Bereitstellung, Routine und Schnittstellen zu NIS2 und DSGVO. Wer die acht im Spätsommer 2026 hat, ist gut aufgestellt. Wer Anfang 2027 noch nicht angefangen hat, läuft Gefahr, die zweite Anwendungs­stufe nicht zu erreichen.