BSI TR-03183: SBOM-Qualitätsstufen und CRA-Konformität

Der CRA schreibt eine Software Bill of Materials vor, überlässt die technischen Details jedoch anderen. Anhang I, Teil II, Punkt (1) fordert eine maschinenlesbare SBOM, die mindestens die direkten Abhängigkeiten des Produkts abdeckt. Damit enden die konkreten Vorgaben der Verordnung. Es gibt keine Feldliste, keine Format-Mindestversion und kein Advisory-Schema. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) hat diese Lücke mit der BSI TR-03183 geschlossen: einer dreiteiligen Technischen Richtlinie, die exakte Formatversionen nennt, alle Pflichtfelder auflistet und die SBOM-Erstellung mit der Veröffentlichung von Sicherheitshinweisen verknüpft. Behandeln Sie sie als die praktische Spezifikation unterhalb der rechtlichen Verpflichtung, nicht als konkurrierende Regulierung.

Was BSI TR-03183 ist

Das BSI ist Deutschlands nationale Cyber-Sicherheitsbehörde. Die Technische Richtlinie TR-03183 trägt den vollständigen Titel Cyber-Resilienz-Anforderungen an Hersteller und Produkte und besteht aus separat nummerierten und versionierten Teilen. Die Richtlinie richtet sich an Hersteller, die sich auf den EU Cyber Resilience Act vorbereiten, und übersetzt die Verpflichtungen aus CRA Anhang I in konkrete, überprüfbare technische Anforderungen.

Die drei Teile des Dokuments mit den zum Zeitpunkt der Erstellung aktuellen Versionen:

Teil	Version	Veröffentlicht	Inhalt
Teil 1	v0.10.0	12.09.2025	Allgemeine CRA-Anforderungen an die Cyber-Resilienz, abgeleitet aus Anhang I, Anhang II und Anhang VII
Teil 2	v2.1.0	20.08.2025	Software Bill of Materials (SBOM): Formate, Felder, Erstellung und Aktualisierung
Teil 3	v1.0.0	20.08.2025	Schwachstellenberichte und -meldungen, einschließlich CVD, security.txt und CSAF-Advisories

Teil 1 §1 beschreibt die Richtlinie als Übergangsinstrument:

"This Technical Guideline will be superseded in the current form as soon as its content is covered by the corresponding standardisation deliverables under the aforementioned standardisation request."

[TRANSLATE: Die aktuell verfügbaren Ausgaben von Teil 1 v0.10.0 und Teil 2 v2.1.0 sind ausschließlich in Englisch veröffentlicht. Eine deutschsprachige Ausgabe von Teil 2 v1.0 (veraltet, CycloneDX 1.4, SPDX 2.3) wurde vom BSI archiviert; der vollständige deutsche Wortlaut des §1 aus Teil 1 v0.10.0 ist in keiner deutschen Fassung zugänglich. Das Zitat wird daher in der englischen Originalfassung belassen.]

Dieser Satz gibt vor, wie Sie TR-03183 einordnen sollten. Sie ist die BSI-Lesart, wie eine CRA-konforme SBOM und ein Schwachstellenprogramm aussehen sollten, während harmonisierte CEN/CENELEC-Normen noch in Ausarbeitung sind. Wenn diese Normen vorliegen, haben sie Vorrang. Bis dahin ist TR-03183 die detaillierteste öffentlich verfügbare Spezifikation, die auf CRA Anhang I ausgerichtet ist.

graph LR
    A[BSI TR-03183]
    A --- P1[Teil 1
Allgemeine CRA-
Anforderungen]
    A --- P2[Teil 2
SBOM]
    A --- P3[Teil 3
Schwachstellenberichte]
    P2 --- F1[CycloneDX 1.6
oder SPDX 3.0.1]
    P2 --- F2[Erforderlich, Zusätzlich
und Optional]
    P3 --- C1[CSAF 2.0
Sicherheitshinweise]
    P3 --- C2[security.txt
CSAF-Tag]
    style A fill:#008080,stroke:#005f5f,color:#fff
    style P1 fill:#e8f4f8,stroke:#008080,color:#333
    style P2 fill:#e8f4f8,stroke:#008080,color:#333
    style P3 fill:#e8f4f8,stroke:#008080,color:#333
    style F1 fill:#f8fafc,stroke:#008080,color:#333
    style F2 fill:#f8fafc,stroke:#008080,color:#333
    style C1 fill:#f8fafc,stroke:#008080,color:#333
    style C2 fill:#f8fafc,stroke:#008080,color:#333

Die CRA-Lücken, die TR-03183 schließt

Sie können die SBOM-Klauseln des CRA von Anfang bis Ende lesen, ohne zu erfahren, welche Felder in Ihr Dokument gehören, welche Formatversion die Anforderung erfüllt oder wie Sie die daraus resultierenden Advisories veröffentlichen. TR-03183 schließt drei konkrete Lücken.

Lücke im CRA-Text	Was TR-03183 festlegt
Anhang I, Teil II, Punkt (1) schreibt eine SBOM vor, nennt aber keine Datenfelder	Teil 2 §5.2 listet Erforderliche, Zusätzliche und Optionale Felder für das SBOM-Dokument und jede Komponente auf
Der CRA verlangt Formate, die „allgemein gebräuchlich und maschinenlesbar" sind, ohne konkrete Formate zu nennen	Teil 2 §4 legt fest: „CycloneDX, Version 1.6 oder höher" oder „System Package Data Exchange (SPDX), Version 3.0.1 oder höher"
Artikel 14 schreibt die Meldung aktiv ausgenutzter Schwachstellen an ENISA vor, ohne ein öffentliches Advisory-Format zu bestimmen	Teil 3 §4.2.8 und §5.1.6 richten Advisories an CSAF 2.0 aus und verweisen auf ISO/IEC 20153:2025

Zum CRA-seitigen Detail dieser Verpflichtungen siehe CRA-SBOM-Anforderungen. Zum Kontext der Fristen und Sanktionen siehe SBOM-Konformitätsfristen und Bußgelder.

Erforderliche, zusätzliche und optionale Felder in Teil 2

Teil 2 v2.1.0 verwendet die Begriffe „Basic", „Standard" oder „Comprehensive" nicht. Jedes Herstellerdiagramm oder jede Zusammenfassung, die drei benannte „Qualitätsstufen" mit diesen Bezeichnungen präsentiert, führt eine Struktur ein, die die Spezifikation nicht enthält. Das Konformitätsmodell in v2.1.0 ist auf Feldebene binär: Ein Feld ist entweder Erforderlich (immer vorhanden), Zusätzlich (verpflichtend, wenn die Daten vorliegen) oder Optional.

Die drei Kategorien mit Verweis auf die Spezifikationsabschnitte:

Kategorie	Spezifikationsabschnitt	Bedeutung	Beispiele
Erforderlich für die SBOM selbst	§5.2.1	Felder auf Dokumentebene, die IMMER vorhanden sein MÜSSEN	Ersteller der SBOM, Zeitstempel
Erforderlich für jede Komponente	§5.2.2	Felder auf Komponentenebene, die IMMER vorhanden sein MÜSSEN	Komponentenname, Version der Komponente, Vertriebslizenzen, Hashwert (SHA-512), Abhängigkeiten von anderen Komponenten, Dateiname, Ausführbar-Eigenschaft, Archiv-Eigenschaft, Strukturiert-Eigenschaft, Ersteller der Komponente
Zusätzlich für jede Komponente	§5.2.4	Verpflichtend, wenn die Daten vorliegen; sonst wegzulassen	Quelltext-URI, URI der einsetzbaren Form der Komponente, Andere eindeutige Bezeichner (CPE, purl), Ursprungslizenzen
Optional für jede Komponente	§5.2.5	DARF angegeben werden	Effektive Lizenz, Hashwert des Quelltexts der Komponente, URL der security.txt

Teil 2 legt in §5.1 außerdem eine rekursive Auflösungspflicht fest: Die rekursive Auflösung von Abhängigkeiten MUSS für jede Komponente im Lieferumfang durchgeführt werden. Das ist die Antwort der Spezifikation auf die vage Formulierung „direkte Abhängigkeiten" in CRA Anhang I, Teil II, Punkt (1): TR-03183 erwartet, dass Sie den gesamten Abhängigkeitsbaum durchlaufen, nicht nur die unmittelbaren Abhängigkeiten.

Anforderungen je Feld

Die vollständige Zuordnung der von Teams am häufigsten nachgefragten Felder zu den v2.1.0-Spezifikationsabschnitten.

Feld	Kategorie	Spezifikationsabschnitt	Hinweise
Ersteller der SBOM	Erforderlich (SBOM-Ebene)	§5.2.1	E-Mail oder URL des Erstellers
Zeitstempel	Erforderlich (SBOM-Ebene)	§5.2.1	ISO 8601
Komponentenname	Erforderlich	§5.2.2	Für jeden Eintrag immer zu befüllen
Version der Komponente	Erforderlich	§5.2.2	Exakte Version, keine Spanne
Ersteller der Komponente	Erforderlich	§5.2.2	Entspricht in älterer Terminologie „Lieferant"
Dateiname der Komponente	Erforderlich	§5.2.2	In der Standard-Tool-Ausgabe oft fehlend
Abhängigkeiten von anderen Komponenten	Erforderlich	§5.2.2	Rekursiv gemäß §5.1
Vertriebslizenzen	Erforderlich	§5.2.2	Lizenzen in der vertriebenen Form
Hashwert der einsetzbaren Komponente	Erforderlich	§5.2.2	SHA-512
Ausführbar-Eigenschaft	Erforderlich	§5.2.2	Boolean: Ist die Komponente ausführbar?
Archiv-Eigenschaft	Erforderlich	§5.2.2	Boolean: Ist die Komponente ein Archiv?
Strukturiert-Eigenschaft	Erforderlich	§5.2.2	Boolean: Indikator für strukturierte Nutzlast
Quelltext-URI	Zusätzlich	§5.2.4	Verpflichtend, wenn bekannt
URI der einsetzbaren Komponente	Zusätzlich	§5.2.4	Verpflichtend, wenn bekannt
Andere eindeutige Bezeichner (CPE, purl)	Zusätzlich	§5.2.4	Verpflichtend, wenn vorhanden; nicht bedingungslos erforderlich
Ursprungslizenzen	Zusätzlich	§5.2.4	Upstream-Lizenz vor dem Vertrieb
Effektive Lizenz	Optional	§5.2.5	Ergebnis der Lizenzabstimmung
Hashwert des Quelltexts	Optional	§5.2.5	Hash des Quellcodes vor dem Build
URL der security.txt	Optional	§5.2.5	Verweis auf den Vulnerability-Disclosure-Einstiegspunkt

Die überraschendste Zeile für viele Teams ist Andere eindeutige Bezeichner (CPE, purl). Teams behandeln Package URLs als Primärschlüssel einer SBOM. Nach TR-03183 Teil 2 v2.1.0 ist purl der Kategorie Zusätzlich zugeordnet: verpflichtend nur, wenn die Daten vorliegen. Der bedingungslose Komponenten-Identifikator ist der SHA-512-Hashwert des einsetzbaren Artefakts, kombiniert mit Name und Version. Wenn Ihr Tooling keinen purl für eine interne Bibliothek berechnen kann, gefährdet das die Konformität nicht. Wenn es den SHA-512 nicht berechnen kann, schon. Verwandte Feldlücken finden Sie unter Häufige SBOM-Fehler.

CycloneDX- und SPDX-Unterstützung

Teil 2 §4 benennt die zulässigen Formate und Mindestversionen:

"A newly generated or updated SBOM MUST be in JSON- or XML-format and a valid SBOM according to one of the following specifications in one of the specified versions: CycloneDX, version 1.6 or higher"

"System Package Data Exchange (SPDX), version 3.0.1 or higher"

[TRANSLATE: Die aktuell veröffentlichte Fassung von Teil 2 v2.1.0 ist ausschließlich in Englisch verfügbar. Der deutschsprachige Wortlaut von §4 aus der archivierten deutschen Ausgabe v1.0 lautet: „Eine SBOM MUSS in einem Format vorliegen, das eine der folgenden Spezifikationen in einer der angegebenen Versionen erfüllt." Die Versionsnummern in v1.0 (CycloneDX 1.4, SPDX 2.3) entsprechen jedoch nicht v2.1.0. Ein wortgetreues deutsches Zitat für v2.1.0 ist nicht verifizierbar; die englischen Originalzitate werden beibehalten.]

Die Release Notes von v2.1.0 dokumentieren auch den Upgrade-Pfad: v2.0.0 (20.09.2024) erhöhte CycloneDX von 1.4 auf 1.5 und SPDX auf 2.2.1. v2.1.0 (20.08.2025) erhöhte CycloneDX von 1.5 auf 1.6 und SPDX von 2.2.1 auf 3.0.1.

Die praktische Konsequenz: Tools, die standardmäßig CycloneDX-1.4-Ausgaben erzeugen (in älteren CI-Konfigurationen noch verbreitet), sind nach v2.1.0 nicht konform. CycloneDX 1.6 führte verfeinerte Unterstützung für kryptografische Assets und ML-BOMs ein; SPDX 3.0.1 ist eine grundlegende Überarbeitung mit einem neuen Nutzlastmodell. Ihre CI-Baseline benötigt ein explizites Flag --spec-version 1.6 oder eine entsprechende Option. Einen Vergleich der beiden Formate und Tool-Reifegrade finden Sie unter CycloneDX vs. SPDX.

Ein auf TR-03183 ausgerichtetes CycloneDX-1.6-Grundgerüst mit den erforderlichen Feldern auf Dokumentebene:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "serialNumber": "urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79",
  "version": 1,
  "metadata": {
    "timestamp": "2027-01-15T10:00:00Z",
    "tools": [
      { "vendor": "Example", "name": "syft", "version": "1.10.0" }
    ],
    "authors": [
      { "name": "Example GmbH security team", "email": "security@example.de" }
    ],
    "component": {
      "type": "firmware",
      "name": "SmartSensor Pro",
      "version": "2.4.1",
      "supplier": { "name": "Example GmbH", "url": ["https://example.de"] },
      "purl": "pkg:firmware/example/smartsensor-pro@2.4.1"
    }
  },
  "components": [
    {
      "type": "library",
      "name": "openssl",
      "version": "3.0.12",
      "purl": "pkg:generic/openssl@3.0.12",
      "licenses": [{ "license": { "id": "Apache-2.0" } }],
      "hashes": [
        { "alg": "SHA-512", "content": "ddaf35a193617aba..." }
      ],
      "supplier": { "name": "OpenSSL Software Foundation" },
      "properties": [
        { "name": "executable", "value": "true" },
        { "name": "archive", "value": "false" }
      ]
    }
  ],
  "dependencies": [
    {
      "ref": "pkg:firmware/example/smartsensor-pro@2.4.1",
      "dependsOn": ["pkg:generic/openssl@3.0.12"]
    }
  ]
}

Die Einträge authors, timestamp und SHA-512-hashes sind die Pflichtfelder auf Dokument- und Komponentenebene, die in CI-Standardkonfigurationen am häufigsten fehlen. Validieren Sie sie mit cyclonedx-cli validate --input-version 1.6, bevor Sie eine Ausgabe als TR-03183-konform einstufen.

Wie TR-03183 CSAF und VEX einordnet

TR-03183 verteilt die SBOM- und Vulnerability-Advisory-Mechanik auf Teil 2 und Teil 3. Die Grundregel ist einfach: CSAF wird in Teil 2 empfohlen und ist für die Veröffentlichung in der security.txt nach Teil 3 operativ erforderlich. VEX ist nie vorgeschrieben.

Mechanismus	TR-03183-Stelle	Verbindlichkeit	Bedeutung
CSAF 2.0 als Advisory-Format	Teil 2 §8.1.14	Empfohlen	„Das empfohlene Format für die Verteilung von Schwachstelleninformationen ist CSAF (einschließlich VEX als Profil)"
security.txt-CSAF-Tag	Teil 3 §4.2.8 (b)	MUSS	Die security.txt-Angabe, die auf CSAF-Dokumente verweist, MUSS mit dem Tag CSAF: beginnen
Anbieter-Metadaten-URI	Teil 3 §4.2.8 (a)	SOLLTE	Hersteller SOLLTEN die URI der provider-metadata.json für CSAF-Dokumente bereitstellen
ISO/IEC 20153:2025	Teil 3 §5.1.6	Referenz	Die internationale Norm für CSAF v2.0
VEX	Teil 2 §1 und §8.1.14	Informativ	VEX erscheint als CSAF-Profil und als einer von mehreren „sollte"-Kanälen für Schwachstelleninformationen

CSAF (Common Security Advisory Framework) Version 2.0 ist ein OASIS-Standard, veröffentlicht am 18. November 2022, mit Errata 01 vom 26. Januar 2024. Er definiert ein JSON-Schema für maschinenlesbare Sicherheitshinweise. Deutsche CERTs (BSI-CERT, CERT-Bund) veröffentlichen und verarbeiten CSAF standardmäßig; der Secvisogram-Editor und der OASIS-CSAF-Validator sind die üblichen Werkzeuge.

Der Zusammenhang mit Artikel 14 ist subtiler als manche Kommentare nahelegen. CRA Artikel 14 legt Meldefristen gegenüber ENISA und dem koordinierenden CSIRT fest: 24 Stunden für die Frühwarnung, 72 Stunden für die Schwachstellenmeldung und 14 Tage für den Abschlussbericht. Er schreibt kein öffentliches Advisory-Format vor. TR-03183 Teil 3 schließt diese Lücke: Nachdem Sie ENISA benachrichtigt haben, ist das CSAF-Dokument, das Sie unter Ihrer security.txt veröffentlichen, das operative Artefakt, das Kunden verarbeiten. Ohne CSAF-Tooling vor dem 11. September 2026 können Sie Artikel 14 noch erfüllen, aber nicht die Beschaffungsanforderungen und security.txt-Erwartungen, die sich aus TR-03183 ergeben.

VEX verdient eine gesonderte Anmerkung. Teil 2 §8.1.14 erwähnt VEX als CSAF-Profil, und Teil 2 §1 nennt es als möglichen Kanal für den „Austausch von Schwachstelleninformationen". Teil 3 erwähnt VEX überhaupt nicht. Aus CRA-Sicht ist VEX nützlich für komponentenbezogene not_affected-Aussagen, die Alert-Fatigue verhindern, wenn eine SBOM eine Bibliothek mit einer bekannten CVE enthält, die aus Ihrem Code heraus nicht erreichbar ist. Es handelt sich um keine TR-03183-Verpflichtung.

Gilt TR-03183 außerhalb Deutschlands?

TR-03183 ist eine deutsche nationale Technische Richtlinie des BSI, keine EU-weite Verordnung. Keiner ihrer drei Teile behauptet eine Anwendbarkeit außerhalb Deutschlands. Teil 1 §1 sieht ausdrücklich vor, durch harmonisierte CEN/CENELEC-Normen abgelöst zu werden, sobald diese im Rahmen des CRA-Normungsauftrags vorliegen.

In der Praxis machen drei Faktoren TR-03183 für Hersteller außerhalb Deutschlands relevant.

Der deutsche Markt ist der größte in der EU, und deutsche Enterprise-Beschaffung referenziert TR-03183 zunehmend explizit. Wenn Sie an deutsche Kunden verkaufen, müssen Sie damit rechnen, TR-03183-Sprache in Sicherheitsfragebögen und Lieferantenverträgen zu finden.

Außerdem gibt es zum Zeitpunkt der Erstellung keine alternative CRA-konforme Spezifikation mit vergleichbarer Detailtiefe. Harmonisierte CEN/CENELEC-Normen unter dem CRA-Normungsauftrag befinden sich noch in Ausarbeitung. TR-03183 ist der derzeit nächste verfügbare Proxy.

Zusätzlich verweist Teil 1 von TR-03183 explizit auf CRA Anhang I, Anhang II und Anhang VII. Ein Hersteller, der seine Dokumentation nach TR-03183 aufbaut, erstellt Anhang-VII-Inhalte (insbesondere Punkte 2(b) und 8 mit SBOMs), die jede EU-Marktüberwachungsbehörde nachvollziehen kann. Den vollständigen Inhalt finden Sie unter Technische Dokumentation nach Anhang VII.

TR-03183 freiwillig umzusetzen ist eine vertretbare technische Entscheidung, außerhalb Deutschlands jedoch keine gesetzliche Anforderung.