Die CRA-SBOM-Anforderungen sind schnell benannt und leicht zu verfehlen: Sie benötigen eine maschinenlesbare SBOM in einem gängigen Format, die mindestens die Top-Level-Abhängigkeiten Ihres Produkts abdeckt. Der CRA verlangt von Herstellern zudem, laufende Prozesse für Schwachstellenmanagement und Dokumentation zu unterhalten, und Marktüberwachungsbehörden können die Unterlagen anfordern, die zum Nachweis der Konformität erforderlich sind. Das deutsche BSI TR-03183 geht bei SBOM-Formaten, -Feldern und -Granularität deutlich stärker ins technische Detail als der CRA selbst.
Der EU Cyber Resilience Act (Verordnung (EU) 2024/2847) ist im Dezember 2024 in Kraft getreten. Er verlangt für jedes Produkt mit digitalen Elementen, das in der EU verkauft wird, eine Software Bill of Materials (SBOM). Beim Detailgrad bleibt das Gesetz jedoch zurückhaltend. Ihre SBOM muss maschinenlesbar sein und mindestens die Top-Level-Abhängigkeiten des Produkts abdecken. Das genaue Format und die minimalen Datenfelder werden später von der Europäischen Kommission über Durchführungsrechtsakte festgelegt.
Bis diese Vorgaben vorliegen, liefert das deutsche BSI die detaillierteste Antwort darauf, was eine SBOM auf CRA-Niveau tatsächlich enthalten sollte. Seine Technische Richtlinie TR-03183 übersetzt die allgemeine Sprache der CRA in konkrete Anforderungen, und Teil 2 behandelt die SBOM.
Zunächst: Was TR-03183 nicht ist
Sie ist kein Gesetz. Das BSI stellt klar, dass die Richtlinie nicht verbindlich ist, nicht als Konformitätsvermutung dienen kann und durch harmonisierte europäische Normen ersetzt wird, sobald diese vorliegen. Sie wortgetreu zu befolgen, macht Sie nicht automatisch CRA-konform.
Was sie bietet, ist die derzeit klarste Vorschau darauf, wohin sich die formalen Regeln entwickeln, formuliert als Anforderungen, an denen Sie sich schon heute messen können. Die Richtlinie besteht inzwischen aus mehreren Teilen:
Teil | Umfang |
|---|---|
Teil 1 | Allgemeine Anforderungen an Hersteller und Produkte |
Teil 2 | Software Bill of Materials (Schwerpunkt dieses Leitfadens) |
Teil 3 | Schwachstellenberichte und -benachrichtigungen |
Modul H | Konformität auf Basis vollständiger Qualitätssicherung |
Teil 2 liegt in Version 2.1.0 vom August 2025 vor. Zwei Dinge sollten Sie zu den Versionen wissen:
Um auf dem aktuellen Stand zu bleiben, verwenden Sie die jeweils aktuelle Version. Die unmittelbar vorhergehende Version ist bis zu sechs Monate nach Erscheinen einer neuen Version zulässig.
Das BSI überarbeitet die Richtlinie regelmäßig. Prüfen Sie bsi.bund.de auf die aktuellste Fassung, bevor Sie sich auf eine bestimmte Version verlassen.
Formatanforderungen
Eine SBOM muss maschinell verarbeitbar sein. Das bedeutet JSON oder XML, in einem von zwei Formaten:
Format | In v2.1.0 zugeordnete Version |
|---|---|
CycloneDX | 1.6 |
SPDX | 3.0.1 |
Version 2.1.0 hat für beide Formate feldgenaue Zuordnungen ergänzt, was das frühere Rätselraten darüber, wie jeder erforderliche Wert dargestellt werden soll, deutlich verringert. Das BSI veröffentlicht außerdem auf GitHub eine CycloneDX-Property-Taxonomie für die Felder, die spezifisch für die Richtlinie sind.
Erstellen Sie für jede Softwareversion eine eigene SBOM. Eine SBOM für eine bestehende Version erzeugen Sie nur dann neu, wenn neue Komponenteninformationen vorliegen oder wenn Sie einen Fehler in den Daten korrigieren.
Inhaltsanforderungen
Die Richtlinie unterscheidet zwischen dem, was das Dokument benötigt, und dem, was jede Komponente benötigt.
Auf Dokumentebene:
Identifizieren Sie den Ersteller, per E-Mail oder ersatzweise per URL.
Erfassen Sie Datum und Uhrzeit der Erhebung der Komponentendaten.
Für jede Komponente:
Feld | Anforderung |
|---|---|
Name und Version | Erforderlich. SemVer oder kalenderbasierte Versionierung bevorzugt. |
Abhängigkeiten | Erforderlich. Erfassen Sie die Komponenten, auf die sich jede stützt, nicht nur eine flache Liste. |
Lizenz | Erforderlich. Verwenden Sie den SPDX-Identifier. Für Lizenzen, die nicht in der SPDX-Liste stehen, sind Ersatzangaben definiert. |
Hash | Erforderlich. SHA-256. |
Quell-/Ausführungs-URI, CPE, PURL | Optional, aber nützlich für Zuordnung und Nachvollziehbarkeit. |
Version 2.1.0 hat außerdem den Lizenzabschnitt überarbeitet und die Behandlung virtueller und referenzierter Komponenten ergänzt. Diese decken Produktteile ab, die keine einfach ausgelieferte Bibliothek sind.
Wo SBOMs und Schwachstellen zusammentreffen
TR-03183 hält Schwachstellendaten bewusst aus der SBOM heraus. Um anzugeben, welche Schwachstellen ein Produkt betreffen und ob sie tatsächlich ausnutzbar sind, verweist die Richtlinie auf CSAF mit einem VEX-Profil. Die beiden Dokumente erfüllen unterschiedliche Aufgaben:
Dokument | Beantwortet |
|---|---|
SBOM | Welche Komponenten in der Software enthalten sind |
VEX / CSAF | Welche Schwachstellen zutreffen und ob sie ausnutzbar sind |
Der Grund für die Trennung ist das Timing. Ein Komponentenverzeichnis ändert sich zwischen Releases kaum. Der Schwachstellenstatus ändert sich täglich. Getrennte Dokumente lassen jedes nach seinem eigenen Takt aktualisieren.
Die Trennung ist zugleich der Punkt, an dem die eigentliche Arbeit beginnt. Zwei Dinge müssen stimmen, bevor eine SBOM brauchbare Schwachstelleninformationen liefert:
Saubere, maschinell abgleichbare Identifier (CPE oder PURL) für jede Komponente.
Vollständige, korrekte Abhängigkeitsbeziehungen.
Am zweiten Punkt scheitern die meisten Tools. Viele Generatoren geben eine Liste von Komponenten aus und lassen die Struktur, die sie verbindet, stillschweigend weg. Sind diese Beziehungen erst einmal verloren, wird die Frage „Betrifft uns dieses neue CVE, und wie tief reicht es?“ zur Spekulation. Eine richtlinienkonforme SBOM ist der Ausgangspunkt. Was sie im Ernstfall wirklich wert ist, hängt von der Tiefe und Genauigkeit dahinter ab.
Ändert Ihre Produktklasse, was die SBOM zeigen muss?
Die meisten Produkte fallen in die Standardkategorie und bewerten sich selbst. Der CRA benennt außerdem zwei höhere Gruppen. Wichtige Produkte (Anhang III) teilen sich in Klasse I, zu der Passwortmanager, VPNs und Netzwerkmanagementsysteme gehören, und Klasse II, die Firewalls und Systeme zur Angriffserkennung umfasst. Kritische Produkte (Anhang IV) stehen über beiden und umfassen Hardware-Sicherheitsmodule und Smart-Meter-Gateways. Die technischen Beschreibungen für jede Gruppe wurden in der Durchführungsverordnung (EU) 2025/2392 festgelegt.
Ihre Klasse ändert nichts am grundlegenden Inhalt der SBOM. Sie ändert, wer sie liest. Ein Standardprodukt darf sich selbst bewerten, Sie sind also Ihr eigener Prüfer. Produkte der Klasse II und kritische Produkte benötigen eine notifizierte Stelle, und Klasse I ebenfalls, sofern Sie nicht die einschlägigen harmonisierten Normen angewendet haben. Sobald ein externer Prüfer Ihre technische Dokumentation liest, lässt sich eine SBOM, die nur die oberste Ebene abdeckt und die Sie selbst durchgewunken hätten, deutlich schwerer verteidigen. Je höher Ihre Klasse, desto weniger Spielraum bleibt, zu wenig zu dokumentieren.
Wie die Meldefrist Ihre SBOM nutzt
Die Meldepflichten des CRA gelten seit dem 11. September 2026, und hier leistet eine SBOM echte Arbeit, statt in einem Ordner zu liegen. Zwei Fristen können anlaufen. Wird eine Schwachstelle in Ihrem Produkt aktiv ausgenutzt, haben Sie 24 Stunden für eine Frühwarnung, 72 Stunden für eine vollständige Meldung und 14 Tage nach Verfügbarkeit einer Behebung oder eines Workarounds für den Abschlussbericht. Bei einem schwerwiegenden Sicherheitsvorfall sind die ersten beiden Schritte gleich, der Abschlussbericht ist jedoch einen Monat nach der 72-Stunden-Meldung fällig. Die Frist beginnt, sobald Sie Kenntnis erlangen, nicht erst, wenn Sie jedes Detail bestätigt haben.
Das ist ein enges Zeitfenster, um eine Frage zu beantworten: Sind wir betroffen, und wo? Wenn das nächste Log4Shell auftaucht, kann ein Team mit einer aktuellen, durchsuchbaren SBOM jedes Produkt und jede ausgelieferte Version in Minuten durchsuchen. Ein Team ohne SBOM durchforstet Build-Logs, während die 24-Stunden-Frist läuft. Die SBOM macht die Frist überhaupt erst machbar.
Was ein Fehler bei der SBOM kostet
Der CRA untermauert seine Anforderungen mit echten Bußgeldern, und diese sind gestaffelt. Die SBOM liegt in der obersten Stufe. Ein Verstoß gegen die grundlegenden Anforderungen oder die Herstellerpflichten aus den Artikeln 13 und 14, wo SBOM-Pflege, Schwachstellenbehandlung und technische Dokumentation angesiedelt sind, kann bis zu 15 Millionen Euro oder 2,5 % des weltweiten Jahresumsatzes kosten, je nachdem, welcher Betrag höher ist. Geringere Verstöße haben niedrigere Obergrenzen: 10 Millionen Euro oder 2 % für sonstige Pflichten und 5 Millionen Euro oder 1 % dafür, einer Behörde falsche oder irreführende Angaben zu machen. Behörden wägen die Verhältnismäßigkeit ab, sodass ein erster Fehltritt kaum das Höchstmaß nach sich zieht. Aber die SBOM ist kein belangloses Kästchen zum Abhaken. Sie fällt unter dieselbe Pflicht, die die höchste Strafe trägt.
Wie das in Ihre CRA-Arbeit passt
Für jeden Hersteller, der nach Deutschland verkauft, ist TR-03183 die Referenz, an der man sich orientieren sollte, und das beste verfügbare Signal für die EU-weiten Regeln, die noch ausgearbeitet werden. Die SBOM ist ein Baustein der EU-Cyber-Resilience-Act-Compliance, die auch Schwachstellenmeldungen, Security-by-Design und technische Dokumentation über den gesamten Unterstützungszeitraum des Produkts umfasst.
Interlynk erzeugt, importiert und reichert SBOMs in CycloneDX und SPDX an, löst den vollständigen Abhängigkeitsbaum mit intakten Beziehungen auf und hält Komponenten und Schwachstellen miteinander verknüpft. Die SBOM, die Sie für die Richtlinie erstellen, bleibt für das Schwachstellenmanagement nützlich, das sie unterstützen soll.
Häufig gestellte Fragen
Verlangt der CRA nur die Top-Level-Abhängigkeiten oder den vollständigen Abhängigkeitsbaum?
Das gesetzliche Minimum sind die Top-Level-Abhängigkeiten. In der Praxis hält eine SBOM, die nur die oberste Ebene abdeckt, selten stand, wenn ein Kunde oder ein Prüfer sie liest. Deshalb dokumentieren die meisten Hersteller den vollständigen transitiven Abhängigkeitsbaum, um zu belegen, dass das Produkt tatsächlich abgedeckt ist.
Welches SBOM-Format verlangt der CRA?
Der CRA-Text verlangt lediglich ein gängiges, maschinenlesbares Format. Die deutsche BSI TR-03183-2 v2.1.0, die maßgebliche Spezifikation, nennt CycloneDX 1.6 oder höher sowie SPDX 3.0.1 oder höher als akzeptierte Formate.
Ab wann gelten die SBOM-Anforderungen des CRA?
Der CRA ist im Dezember 2024 in Kraft getreten und gilt stufenweise. Die Meldepflichten für Schwachstellen nach Artikel 14 gelten seit dem 11. September 2026, und die vollständigen Anforderungen einschließlich der SBOM gelten ab dem 11. Dezember 2027.
Muss man die SBOM nach dem CRA veröffentlichen?
Nein. Die SBOM wird in der technischen Dokumentation aufbewahrt und nicht veröffentlicht. Marktüberwachungsbehörden können sie anfordern, und Sie können sie zu Ihren eigenen Bedingungen mit Kunden teilen.
Gilt die BSI TR-03183 für den CRA?
Ja. Die BSI TR-03183-2 ist die deutsche technische Richtlinie, die die SBOM-Anforderung des CRA operationalisiert. Sie definiert die verpflichtenden Datenfelder, die akzeptierten Formate und die erwartete Detailtiefe. Sie ist die praktische Referenz, um den CRA im Bereich SBOM zu erfüllen.