CRA-SBOM-Pflichten: Format, Umfang, Updates und Aufbewahrung
Für CRA-Compliance benötigt der Hersteller eine maschinenlesbare Software Bill of Materials (SBOM), die Softwarekomponenten identifiziert und die Schwachstellenbehandlung für das auf dem EU-Markt bereitgestellte Produkt stützt. Die gesetzliche Mindestanforderung ist die Abdeckung mindestens der obersten Abhängigkeiten in einem gängigen, maschinenlesbaren Format. CycloneDX und SPDX sind die praktischen Formate, die die meisten Teams verwenden. Die SBOM gehört in die technische Dokumentation, wird normalerweise nicht proaktiv eingereicht und muss bei einem begründeten Verlangen der Marktüberwachung verfügbar sein.
Zusammenfassung
- Jedes Produkt mit digitalen Elementen benötigt eine maschinenlesbare SBOM als Teil der Hersteller-Nachweise zur Schwachstellenbehandlung.
- Der gesetzliche Mindestumfang sind oberste Abhängigkeiten; die Abdeckung transitiver Abhängigkeiten ist die stärkere Praxis und wird von vielen SBOM-Qualitätsrahmen erwartet.
- Der CRA verlangt ein gängiges und maschinenlesbares Format. CycloneDX und SPDX sind die praktischen Optionen; PDFs und Tabellen ersetzen die SBOM nicht.
- Die SBOM liegt in der technischen Dokumentation und muss für ein begründetes Marktüberwachungsverlangen auffindbar sein.
- Halten Sie die SBOM während des Supportzeitraums dort aktuell, wo es angemessen ist, insbesondere nach Releases, Komponentenänderungen und Schwachstellenentscheidungen.
- Die volle CRA-Anwendung beginnt am 11. Dezember 2027; die Schwachstellenmeldung beginnt früher, am 11. September 2026.
Was ist eine SBOM?
Eine Software Bill of Materials (SBOM) ist ein strukturiertes Verzeichnis aller Softwarekomponenten in einem Produkt: Bibliotheken, Frameworks, Betriebssystempakete und deren Abhängigkeiten. Sie funktioniert wie eine Zutatenliste für Software: Sie zeigt, was enthalten ist, damit Käufer, Behörden und Sicherheitsteams Risiken bewerten, Schwachstellen verfolgen und Lizenz-Compliance prüfen können.
Der rechtliche SBOM-Mindestumfang
Die SBOM-Pflicht hat zwei praktische Ebenen: was das Verzeichnis abdecken muss und wo der Nachweis in der technischen Dokumentation liegt.
Komponenten- und Schwachstellennachweis
Hersteller müssen Schwachstellen und Komponenten in Produkten mit digitalen Elementen ermitteln und dokumentieren. Der CRA sagt, dass dies auch die Erstellung einer SBOM in einem gängigen und maschinenlesbaren Format umfasst, die mindestens die obersten Abhängigkeiten des Produkts abdeckt.
Das bedeutet:
- SBOMs sind verpflichtend, nicht optional.
- Sie müssen maschinenlesbar sein. Ein PDF- oder Tabellenexport kann die menschliche Prüfung unterstützen, ersetzt aber nicht die SBOM-Datei.
- Sie müssen mindestens die obersten Abhängigkeiten abdecken. Transitive Abhängigkeiten gehen über die reine Mindestanforderung hinaus, sind aber die bessere Arbeitsgrundlage für Schwachstellenüberwachung.
Jedes Produkt mit digitalen Elementen, das auf dem EU-Markt bereitgestellt wird, muss eine maschinenlesbare SBOM haben. Es gibt keine Ausnahme und keine Größenschwelle, unterhalb derer die Pflicht entfällt.
Wo die SBOM in der technischen Dokumentation liegt
Die technische Dokumentation behandelt die SBOM auf zwei Arten:
- Der Nachweis der Schwachstellenbehandlung muss die SBOM zusammen mit der koordinierten Offenlegungspolitik, der Kontaktadresse und dem Ansatz für die sichere Update-Verteilung enthalten.
- Soweit zutreffend, muss die SBOM für ein begründetes Verlangen einer Marktüberwachungsbehörde verfügbar sein.
Die SBOM wird nicht proaktiv eingereicht. Sie muss bestehen, wenn das Produkt auf dem EU-Markt bereitgestellt wird, und auf Anfrage für Behörden verfügbar sein.
Praktisch sollte die SBOM Schwachstellenverfolgung auf Komponentenebene, Lieferanten- und Herkunftsprüfung, Lizenzprüfung und End-of-Life-Planung ermöglichen.
Was die SBOM enthalten muss
Trennen Sie den CRA-Mindestumfang von den Feldern, die die SBOM im echten Schwachstellen-Workflow nutzbar machen. Die Verordnung setzt das Minimum. TR-03183, CycloneDX/SPDX-Werkzeuge und Kundenerwartungen setzen die operative Messlatte meist höher.
| Bereich | CRA-Mindestanforderung | Starke Umsetzung |
|---|---|---|
| Format | Gängig und maschinenlesbar | CycloneDX JSON/XML oder SPDX JSON/tag-value, durch Build-Tools erzeugt |
| Umfang | Mindestens oberste Abhängigkeiten | Direkte und transitive Abhängigkeiten, interne Bibliotheken, Firmware und Betriebssystempakete, soweit zutreffend |
| Komponenten | Im Produkt enthaltene Komponenten | Komponentenname, Version, Lieferant, PURL oder CPE, Hash und Beziehungsdaten |
| Schwachstellen | Schwachstellen als Teil der Behandlungsprozesse dokumentiert | Aktueller Schwachstellenstatus, VEX- oder Ausnutzbarkeitsentscheidung, Remediation-Referenz und Prüftermin |
| Technischer Nachweis | SBOM im Nachweis der Schwachstellenbehandlung enthalten | Stabile Dateireferenz je Produktversion, Generierungstool, Erstellungsdatum und Validierungsergebnis |
| Behördenzugang | Bei Bedarf für ein begründetes Marktüberwachungsverlangen verfügbar | Sicheres Archiv mit Abrufverantwortlichem, Integritätskontrollen und Supportzeitraum-Abdeckung |
Spezifische Feldanforderungen, die über diese Checkliste hinausgehen (PURL-Kennungen, Hash-Werte, Dokumentmetadaten), finden Sie unter wie BSI TR-03183 den CRA erweitert. Einen Vergleich von CycloneDX- und SPDX-Werkzeugen finden Sie unter CycloneDX vs. SPDX.
Wie ein konformer SBOM-Eintrag aussieht
Ein starker Eintrag in der technischen Dokumentation verweist auf die maschinenlesbare SBOM und dokumentiert den Schwachstellenstatus zum Bewertungszeitpunkt:
SOFTWARE BILL OF MATERIALS
Product: SmartSense Pro (SSP-3000)
Firmware Version: 2.4.1
SBOM Format: CycloneDX 1.5
Generated: 2027-01-15
Tool: Trivy + syft
SBOM FILE:
sbom-ssp3000-v2.4.1.json (attached)
COMPONENT SUMMARY:
-------------------------------------------------------------
Total Components: 127
Direct Dependencies: 23
Transitive Dependencies: 104
By Type:
Libraries: 98
Frameworks: 12
Operating System: 1 (FreeRTOS)
Firmware Modules: 16
VULNERABILITY STATUS AT ASSESSMENT:
-------------------------------------------------------------
Scan Date: 2027-01-15
Scanner: Trivy v0.48.0
Critical: 0
High: 0
Medium: 2 (accepted - see below)
ACCEPTED VULNERABILITIES:
CVE-2026-XXXXX (Medium): Component xyz v1.2.3
Status: Not exploitable in our configuration
Justification: Feature not enabled, code path not reachable
Review Date: 2027-04-15
-------------------------------------------------------------
SBOM UPDATE COMMITMENT:
SBOM will be updated with each firmware release and made
available to customers upon request.
Wann Sie Ihre SBOM aktualisieren müssen
Die SBOM ist kein einmaliges Dokument. Die technische Dokumentation muss vor der Bereitstellung des Produkts auf dem Markt erstellt und während des Supportzeitraums dort aktualisiert werden, wo es angemessen ist.
Prüfen oder regenerieren Sie die SBOM, wenn:
| Auslöser | Was sich ändert | Praktische Maßnahme |
|---|---|---|
| Neue Firmware- oder Softwareversion | Neues Build-Artefakt | SBOM für diese Produktversion neu erzeugen |
| Sicherheits-Patch | Komponentenversion ändert sich | Betroffene Komponenten aktualisieren und neue SBOM archivieren |
| Schwachstelle entdeckt und bewertet | VEX- oder Ausnutzbarkeitsstatus ändert sich | Schwachstellenstatus und Entscheidungsnachweis aktualisieren |
| Komponente hinzugefügt, entfernt oder ersetzt | Abhängigkeitsgraph ändert sich | SBOM neu erzeugen und validieren |
| Sicherheitsrelevante Designänderung | Komponenten oder Architektur ändern sich | SBOM neu erzeugen und technische Referenzen aktualisieren |
| Angewandte Normen oder Spezifikationen ändern sich | Compliance-Metadaten ändern sich | Metadaten und verknüpfte Nachweise prüfen |
Regelmäßige Überprüfungen:
| Turnus | Umfang |
|---|---|
| Vierteljährlich | SBOM und Schwachstellenstatus |
| Jährlich | Vollständige Überprüfung der technischen Dokumentation |
| Vor Ende des Supportzeitraums | Abschließendes Einfrieren der Dokumentation |
Eine manuelle SBOM-Erstellung ist fehleranfällig und skaliert nicht über Produktversionen hinweg. Jeder Build sollte ein aktuelles SBOM-Artefakt erzeugen. Was schiefgeht, wenn Teams die Automatisierung überspringen, beschreiben die häufigen SBOM-Fehler.
Wie lange SBOM-Nachweise aufzubewahren sind
Bewahren Sie die SBOM mit der technischen Dokumentation mindestens 10 Jahre nach dem Inverkehrbringen des Produkts mit digitalen Elementen auf, oder für den Supportzeitraum, wenn dieser länger ist. Dieselbe Aufbewahrungsregel gilt für die technische Dokumentation und die EU-Konformitätserklärung.
Bei einer Produktlinie, die über längere Zeit verkauft wird, sollten Nachweise für die Versionen und Einheiten aufbewahrt werden, die auf den Markt gebracht wurden. Behandeln Sie das erste Launch-Datum nicht als praktisches Ende der Nachweispflicht, solange spätere Einheiten oder Versionen weiterhin bereitgestellt werden.
| Meilenstein | Beispieldatum |
|---|---|
| Produkt erstmals auf dem Markt bereitgestellt | März 2027 |
| Letzte Einheit auf dem Markt bereitgestellt | Dezember 2030 |
| Praktische Nachweisabdeckung | Bis Dezember 2040 oder länger, wenn der Supportzeitraum es verlangt |
Bewahren Sie die SBOM in einem sicheren, zugänglichen Speicher mit Backup-Verfahren, Integritätsschutz und der Möglichkeit auf, sie bei einem begründeten Verlangen einer Marktüberwachungsbehörde abzurufen und bereitzustellen.
Termine und Durchsetzung
Die volle CRA-Anwendung beginnt am 11. Dezember 2027. Die Schwachstellenmeldepflicht beginnt früher, am 11. September 2026. Dieses frühere Datum ist keine separate SBOM-Einreichungsfrist, verlangt aber, dass Hersteller schnell erkennen können, welche Produktversionen und Komponenten von einer meldepflichtigen Schwachstelle oder einem meldepflichtigen Vorfall betroffen sind. Für Produkte, die nach Beginn der vollen Anwendung auf dem EU-Markt bereitgestellt werden, ist die SBOM Teil der Nachweisbasis hinter Konformitätsbewertung, EU-Konformitätserklärung und CE-Kennzeichnung. Den Ablauf der Artikel-14-Meldung finden Sie unter CRA-Schwachstellen- und Vorfallmeldung. Den allgemeinen CRA-Zeitplan finden Sie unter Was ist der CRA?; die Sanktionsübersicht unter CRA-Bußgelder und Durchsetzung.
Häufig gestellte Fragen
Schreibt der CRA eine maschinenlesbare SBOM vor oder reicht ein PDF?
Die SBOM muss in einem gängigen, maschinenlesbaren Format vorliegen. Ein PDF oder eine Tabelle kann die Datei für menschliche Prüfung begleiten, ersetzt die SBOM aber nicht. CycloneDX oder SPDX als JSON oder XML ist der praktische Weg.
Schreibt der CRA eine SBOM auch für Open-Source-Komponenten vor?
Ja. Open-Source-Komponenten sind weiterhin Komponenten im Produkt. Wenn eine Open-Source-Bibliothek im Produkt enthalten ist, sollte sie mit Version und Kennung in der SBOM erscheinen, damit Schwachstellen verfolgt und behandelt werden können.
Wann muss eine SBOM eingereicht werden: bei Marktbereitstellung oder auf Anfrage?
Die SBOM wird normalerweise nicht proaktiv eingereicht. Sie muss Teil der technischen Dokumentation sein, für Marktüberwachungsbehörden bei begründetem Verlangen verfügbar sein und bestehen, wenn das Produkt auf dem EU-Markt bereitgestellt wird.
Was sind die NTIA-Mindestfelder und erfüllen sie die CRA-Anforderungen?
Die NTIA-Mindestfelder (Lieferantenname, Komponentenname, Version, eindeutige Kennungen, Abhängigkeitsbeziehungen, SBOM-Autor und Zeitstempel) sind ein sinnvoller Ausgangspunkt. Sie beantworten aber nicht jede CRA-Nachweisfrage und nicht jede TR-03183-Qualitätserwartung. Für CRA-Arbeit sollten Sie die erzeugte Datei gegen das gewählte Format validieren, den Schwachstellenstatus dokumentieren und reichere Felder wie PURL/CPE, Hashes und Beziehungsdaten ausfüllen, wenn Ihr Qualitätsrahmen sie verlangt.
Kann ich SBOMs von Lieferanten wiederverwenden, um den CRA zu erfüllen?
Teilweise. Lieferanten-SBOMs sind gültige Eingaben für die von ihnen gelieferten Komponenten, aber der Hersteller des integrierten Produkts benötigt weiterhin eine SBOM für das Produkt, wie es auf den Markt gebracht wird. Das bedeutet, Lieferanten-SBOMs mit eigenen Komponenten, Build-Abhängigkeiten und Produktversionsnachweisen zu konsolidieren. Behandeln Sie Lieferanten-SBOMs als Rohmaterial, nicht als fertiges Compliance-Artefakt.