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.
Formaatvereisten
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.
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.