BSI TR-03183: Die deutsche SBOM-Norm für CRA

Was ist BSI TR-03183?

BSI TR-03183 ist eine technische Richtlinie des Bundesamts für Sicherheit in der Informationstechnik (BSI), die konkrete Anforderungen an das Schwachstellenmanagement und die SBOM-Erstellung für CRA-konforme Produkte definiert. Sie besteht aus drei Teilen:

• Teil 1: Allgemeine Anforderungen an das Schwachstellenmanagement für Hersteller
• Teil 2: Anforderungen an Software Bills of Materials (SBOM) — Pflichtfelder, Formate, Tiefe
• Teil 3: Anforderungen an Vulnerability Reports und Notifications (CSAF-Format)

Die Richtlinie ist kein eigenständiges Rechtsdokument, sondern eine technische Konkretisierung der CRA-Anforderungen für den deutschen Markt. Wer BSI TR-03183 einhält, erfüllt die CRA-SBOM-Anforderungen in Deutschland.

TR-03183-1: Allgemeine Anforderungen an Hersteller

Teil 1 beschreibt den organisatorischen Rahmen für das Schwachstellenmanagement:

• Aufbau und Betrieb eines Schwachstellenmanagement-Prozesses
• Verantwortlichkeiten und Eskalationspfade (intern: wer entscheidet über Meldungen?)
• Koordiniertes Vorgehen mit nationalen und europäischen Behörden
• Pflicht zur Veröffentlichung einer Disclosure Policy (security.txt)
• Dokumentationsanforderungen für Audit-Nachweise

TR-03183-2: SBOM-Anforderungen im Detail

Teil 2 ist der für die meisten Hersteller relevanteste Abschnitt. Er definiert präzise, was eine CRA-konforme SBOM enthalten muss:

Pflicht-Metadaten (Top-Level):

• Hersteller-Identifikation (Name, URL)
• Produkt-Identifikation (Name, Version, CPE oder PURL)
• Zeitstempel der SBOM-Erstellung
• SBOM-Format und Version (CycloneDX 1.6 oder SPDX 3.0)

Pflicht-Felder pro Komponente:

• Name und Version der Komponente
• Hersteller / Maintainer der Komponente
• PURL (Package URL) als eindeutiger Identifier
• Lizenz (SPDX-Lizenz-ID)
• Abhängigkeitstiefe (direkte vs. transitive Dependency)
• Hash-Wert (SHA-256) der Komponente

TR-03183-3: Vulnerability Reports und Notifications

Teil 3 beschreibt die Anforderungen an maschinenlesbare Sicherheitshinweise im CSAF-Format:

• CSAF-Advisory: Öffentlicher Sicherheitshinweis im CSAF-2.0-Format für bekannte Schwachstellen
• VEX (Vulnerability Exploitability Exchange): Maschinenlesbare Aussage über die Ausnutzbarkeit einer CVE im spezifischen Produkt-Kontext
• Notification an Kunden: Strukturierte Benachrichtigung betroffener B2B-Kunden bei kritischen Schwachstellen

Praktische Umsetzung: Welche SBOM-Felder muss ich befüllen?

Für eine BSI TR-03183-2-konforme SBOM sind mindestens folgende Felder erforderlich. Hier am Beispiel eines npm-Pakets:

{
  "type": "library",
  "name": "express",
  "version": "4.18.2",
  "purl": "pkg:npm/express@4.18.2",
  "supplier": "OpenJS Foundation",
  "licenses": [{ "license": { "id": "MIT" } }],
  "hashes": [{ "alg": "SHA-256", "content": "abc123..." }],
  "scope": "required"
}

Transitive Dependencies müssen mit scope: "optional" oder scope: "excluded" markiert werden, um die Abhängigkeitstiefe transparent zu machen.

CycloneDX vs. SPDX nach BSI TR-03183-2

BSI TR-03183-2 erkennt beide Formate als konform an — mit unterschiedlichen Stärken:

• CycloneDX 1.6 (empfohlen für operative Nutzung): Nativer Support für VEX, CSAF-Integration und Security-Operations. Bevorzugtes Format für den ENISA-SRP-Meldeprozess.
• SPDX 3.0 (empfohlen für Lizenz-Compliance und Austausch): Breitere Tool-Unterstützung, ISO-Standard (ISO/IEC 5962:2021), bevorzugtes Format für OEM-Lieferantenverträge.

Unsere Empfehlung: CycloneDX als operatives Format für den täglichen Vulnerability-Abgleich und die ENISA-Meldung, SPDX als Austauschformat für Kunden-Audits und OEM-Nachweise. Mehr dazu auf der SBOM-Formate-Vergleichsseite.

SBOMfunk und BSI TR-03183-2: Was automatisch korrekt ist

SBOMfunk generiert SBOMs, die BSI TR-03183-2 ab der ersten Generierung erfüllen — ohne manuelle Konfiguration:

• Alle Pflichtfelder (PURL, Hashes, Lizenzen, Supplier) werden automatisch befüllt
• CycloneDX 1.6 und SPDX 3.0 werden parallel generiert
• Abhängigkeitstiefe (direkt vs. transitiv) wird automatisch klassifiziert
• VEX-Statements werden aus dem Vulnerability-Dashboard generiert
• CSAF-Advisories für die ENISA-SRP-Meldung werden automatisch erstellt

Von der BSI-Norm zur CRA-Pflicht: Was jedes Feld bedeutet

Jedes Pflichtfeld der BSI TR-03183-2 hat eine direkte Entsprechung in einem Artikel des Cyber Resilience Act. Die folgende Zuordnung zeigt, warum die Felder nicht nur formal existieren, sondern operative Bedeutung haben:

• Hersteller-Identifikation ↔ CRA Art. 13(5): Verantwortlichkeit und Erreichbarkeit für Aufsichtsbehörden.
• Produkt-Identifikation (Name, Version, CPE/PURL) ↔ CRA Art. 13(3): Eindeutige Identifizierbarkeit des Produkts im Markt.
• Zeitstempel der SBOM-Erstellung ↔ CRA Art. 13(7): Nachweis der Aktualität — wichtig bei Sicherheitsvorfällen.
• SBOM-Format und Version ↔ CRA Art. 13(8): Maschinenlesbare Bereitstellungspflicht.
• Komponenten-Name + Version ↔ CRA Art. 13(5): Voraussetzung für Vulnerability-Matching.
• Supplier / Maintainer pro Komponente ↔ CRA Art. 13(9): Lieferketten-Transparenz.
• PURL ↔ CRA Art. 13(5): Eindeutiger Identifier für Vulnerability-Datenbanken.
• Lizenz (SPDX-ID) ↔ CRA Art. 13(6): Lizenz-Compliance für Drittkomponenten.
• Abhängigkeitstiefe (direkt vs. transitiv) ↔ CRA Art. 13(5): Notwendig für korrekte Impact-Analyse bei CVEs.
• Hash-Wert (SHA-256) ↔ CRA Art. 13(5): Integritätsnachweis — schützt gegen Manipulation.
• VEX-Statements ↔ CRA Art. 14: Pflicht zur Aussage über Ausnutzbarkeit im Produkt-Kontext.
• CSAF-Advisory ↔ CRA Art. 14: Pflichtformat für Schwachstellenmeldungen an die ENISA.

Diese Felder sind keine Formalität: ohne sie ist eine ENISA-konforme Meldung über die Single Reporting Platform technisch nicht möglich. SBOMfunk befüllt alle zwölf Felder automatisch — ohne manuelle Konfiguration.