CRA-SBOM-Pflichten: Format, Umfang, Updates und Aufbewahrung
Der CRA verlangt, dass jedes Produkt mit digitalen Elementen mit einer maschinenlesbaren Software Bill of Materials (SBOM) ausgeliefert wird, die seine Softwarekomponenten auflistet und mindestens deren oberste Abhängigkeiten abdeckt. Die SBOM liegt in Ihrer technischen Dokumentation und muss für eine Marktüberwachungsbehörde auf Anfrage bereitstehen, sie wird nicht vorab eingereicht.
Zusammenfassung
- Jedes Produkt mit digitalen Elementen benötigt eine maschinenlesbare SBOM als Teil der Nachweise zur Schwachstellenbehandlung. Sie ist verpflichtend, ohne größenbasierte Ausnahme.
- Der gesetzliche Mindestumfang sind oberste Abhängigkeiten. Transitive Abdeckung ist die stärkere Praxis und das, was die meisten SBOM-Qualitätsrahmen erwarten.
- Ein Produkt bedeutet einen zusammenhängenden SBOM-Nachweis, auch wenn das Produkt aus vielen Repositories oder Komponenten besteht.
- Halten Sie die SBOM während des Supportzeitraums aktuell, insbesondere nach Releases, Komponentenänderungen und Schwachstellenentscheidungen.
- Bewahren Sie die SBOM mit der technischen Dokumentation mindestens 10 Jahre auf, oder für den Supportzeitraum, wenn dieser länger ist.
- Die Schwachstellenmeldung beginnt am 11. September 2026; die volle CRA-Anwendung am 11. Dezember 2027.
Was ist eine SBOM?
Eine Software Bill of Materials (SBOM) ist ein strukturiertes Verzeichnis der Software in einem Produkt: Bibliotheken, Frameworks, Betriebssystempakete und die Abhängigkeiten zwischen ihnen. Für den CRA ist sie die Aufzeichnung, anhand derer eine Marktüberwachungsbehörde prüfen würde, welche Ihrer Komponenten von einer gemeldeten Schwachstelle betroffen sind. Deshalb muss sie maschinenlesbar sein und nicht als Fließtextdokument vorliegen.
Was der CRA in einer SBOM verlangt
Die SBOM-Pflicht hat zwei praktische Ebenen: was das Verzeichnis abdecken muss und wo der Nachweis in der technischen Dokumentation liegt.
Welche Komponenten muss die SBOM abdecken?
Hersteller müssen die Komponenten und Schwachstellen in ihren Produkten mit digitalen Elementen ermitteln und dokumentieren und eine SBOM in einem gängigen, maschinenlesbaren Format erstellen, die mindestens die obersten Abhängigkeiten des Produkts abdeckt.
Das bedeutet:
- Die SBOM muss maschinenlesbar sein und in einem gängigen Format vorliegen. Ein PDF oder eine Tabelle kann Menschen bei der Prüfung des Verzeichnisses helfen, ersetzt aber nicht die SBOM-Datei.
- Sie muss mindestens die obersten Abhängigkeiten abdecken. Transitive Abdeckung geht über die reine Mindestanforderung hinaus und ist die bessere Arbeitsgrundlage für die 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. Wie viele Details Sie dokumentieren, richtet sich nach dem Risiko des Produkts, die Pflicht zur Erstellung einer SBOM bleibt aber davon unberührt.
Aktuell verlangen die Regeln nur ein gängiges, maschinenlesbares Format, das mindestens die obersten Abhängigkeiten abdeckt. Sie nennen kein bestimmtes Format und keine feste Feldliste. Diese Mindestanforderung kann angehoben werden: Der CRA lässt der Kommission Raum, später ein genaues SBOM-Format und einen festen Feldsatz festzulegen. Wer jetzt ein gut unterstütztes Format wählt, CycloneDX oder SPDX, und mehr als das absolute Minimum erfasst, sichert sich am besten gegen ein künftig vorgeschriebenes Format ab.
Wo die SBOM in der technischen Dokumentation liegt
Die SBOM ist Teil Ihrer technischen Dokumentation und liegt neben den übrigen Nachweisen zur Schwachstellenbehandlung: der koordinierten Offenlegungspolitik, einer Kontaktadresse für Meldungen und der Beschreibung, wie Sie Updates sicher verteilen. Sie reichen sie nicht vorab ein. Sie muss bestehen, wenn das Produkt auf dem EU-Markt bereitgestellt wird, und für eine Marktüberwachungsbehörde bereitstehen, falls diese ein begründetes Verlangen stellt.
In der Praxis sollte die SBOM Ihnen Schwachstellenverfolgung auf Komponentenebene, Lieferanten- und Herkunftsprüfung, Lizenzprüfung und End-of-Life-Planung ermöglichen.
Wie viele SBOMs braucht ein Produkt?
Ein Produkt besteht oft aus vielen Repositories und Komponenten, und jede kann ihre eigene SBOM ausgeben. Der CRA legt die Nachweiseinheit auf das Produkt fest, nicht auf das Repository oder den Build.
Der CRA definiert eine SBOM als Aufzeichnung der Komponenten in der Software eines Produkts und ihrer Beziehungen zueinander, und er erwartet, dass diese Aufzeichnung mindestens die obersten Abhängigkeiten des Produkts abdeckt. Das Nachweisobjekt ist das Produkt, das Sie auf dem EU-Markt bereitstellen, identifiziert über Produkt und Version. Ein aus zehn Repositories zusammengesetztes Produkt ist nicht durch zehn lose Komponenten-SBOMs abgedeckt, die nichts miteinander verbindet. Sie schulden einen SBOM-Nachweis, der das Produkt so abbildet, wie es ausgeliefert wird.
Der CRA schreibt keine einzelne physische Datei vor, und er verbietet nicht, Komponenten-SBOMs zu führen. Zwei Wege funktionieren beide, solange das Ergebnis maschinenlesbar ist, auf Produktebene liegt und mindestens die obersten Abhängigkeiten abdeckt:
- Zusammensetzen. Führen Sie Komponenten-SBOMs als separate Dokumente und verknüpfen Sie sie zu einer Produkt-SBOM, über CycloneDX-Assembly-Komponenten mit BOM-Link-Referenzen oder SPDX-Beziehungen mit Verweisen auf externe Dokumente.
- Zusammenführen. Fassen Sie jede Komponente in einem einzigen CycloneDX- oder SPDX-Dokument für die Produktversion zusammen.
Weil die SBOM erfassen soll, wie Komponenten zusammenhängen, reicht eine flache Liste von Paketnamen für sich allein nicht aus. Welchen Weg Sie auch wählen, die SBOM sollte zeigen, wie Komponenten voneinander abhängen und einander enthalten, was sowohl CycloneDX-Abhängigkeitsgraphen als auch SPDX-Beziehungen leisten. Zu den Format-Details siehe CycloneDX vs. SPDX.
Wer muss die SBOM erhalten?
Die SBOM ist Material der technischen Dokumentation, kein öffentliches Dokument. Der CRA verlangt nicht, dass Sie sie veröffentlichen, und die einzige Stelle, die sie verlangen kann, ist eine Marktüberwachungsbehörde, die sie bei einem begründeten Verlangen anfordern kann, wenn sie Ihre Konformität prüfen muss. Die SBOM mit Nutzern zu teilen, ist freiwillig. Wenn Sie sich entscheiden, sie mit Nutzern zu teilen, müssen Sie ihnen anschließend mitteilen, wo sie zu finden ist.
| Wer | Was der CRA erwartet |
|---|---|
| Marktüberwachungsbehörde | Kann die SBOM bei einem begründeten Verlangen anfordern, wenn sie zur Konformitätsprüfung benötigt wird |
| Nutzer und Öffentlichkeit | Keine Pflicht zur Veröffentlichung oder Herausgabe; das Teilen ist Ihre Entscheidung |
| Einführer und Händler | Kein Anspruch auf die SBOM selbst; sie müssen Behörden auf Anfrage Ihre technische Dokumentation beschaffen können |
| Integratoren, die auf Ihrem Produkt aufbauen | Wenn Ihr Produkt in deren Produkt integriert werden soll, geben Sie ihnen die Informationen, die sie für ihre eigenen Pflichten benötigen, was nicht automatisch die vollständige SBOM ist |
Veröffentlichen Sie die SBOM nicht und schieben Sie sie Nutzern nicht standardmäßig zu. Eine SBOM ist eine präzise Karte Ihrer Komponenten und Versionen, also genau das, was ein Angreifer will, und der CRA verpflichtet Sie nicht, sie breit herauszugeben. Geben Sie sie an eine Marktüberwachungsbehörde, wenn diese ein begründetes Verlangen stellt, und an Geschäftskunden, die auf Ihrem Produkt aufbauen, unter einer Geheimhaltungsvereinbarung oder einem Vertrag, weil sie sie brauchen, um ihre eigene SBOM auf Produktebene zusammenzustellen und ihre eigenen Pflichten zu erfüllen. Halten Sie fest, wer welche Version erhalten hat.
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 | Ermittelte und dokumentierte Komponenten und Schwachstellen | 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 |
Der CRA verlangt von Ihnen, Schwachstellen zu ermitteln und zu dokumentieren, das bedeutet aber nicht, dass die Schwachstellen- oder VEX-Daten in der SBOM-Datei selbst liegen müssen. Sie dort zu führen, ist gute Praxis, keine Mindestanforderung. Zu den Feldanforderungen, die über diese Checkliste hinausgehen (PURL-Kennungen, Hash-Werte, Dokumentmetadaten), siehe wie BSI TR-03183 den CRA erweitert. Einen Vergleich von CycloneDX- und SPDX-Werkzeugen finden Sie unter CycloneDX vs. SPDX.
Wie eine SBOM-Zusammenfassung im technischen File aussieht
Ein starkes technisches File verbindet die maschinenlesbare SBOM mit einer kurzen Zusammenfassung. Die Zusammenfassung ist ein Deckblatt für die menschliche Prüfung. Die eigentliche SBOM ist die angehängte CycloneDX- oder SPDX-Datei, auf die sie verweist.
SBOM-ZUSAMMENFASSUNG (TECHNISCHES FILE)
Product: SmartSense Pro (SSP-3000)
Firmware Version: 2.4.1
SBOM Format: CycloneDX 1.6
Generated: 2027-01-15
Tools: Syft (Generierung), Trivy (Scan)
SBOM-DATEI:
sbom-ssp3000-v2.4.1.json (angehängt, maschinenlesbar)
KOMPONENTENÜBERSICHT:
-------------------------------------------------------------
Komponenten gesamt: 127
Direkte Abhängigkeiten: 23
Transitive Abhängigkeiten: 104
Nach Typ:
Bibliotheken: 98
Frameworks: 12
Betriebssystem: 1 (FreeRTOS)
Firmware-Module: 16
SCHWACHSTELLENSTATUS ZUM BEWERTUNGSZEITPUNKT:
-------------------------------------------------------------
Scan-Datum: 2027-01-17
Scanner: Trivy v0.48.0
Kritisch: 0
Hoch: 0
Mittel: 2 (akzeptiert, siehe unten)
AKZEPTIERTE SCHWACHSTELLEN:
CVE-2026-15432 (Mittel): libexpat 2.5.0
Status: In unserer Konfiguration nicht ausnutzbar
Begründung: Funktion nicht aktiviert, Code-Pfad nicht erreichbar
Prüftermin: 2027-04-15
-------------------------------------------------------------
Wann Sie Ihre SBOM aktualisieren müssen
Die SBOM ist kein einmaliges Dokument. Ihre technische Dokumentation muss vor der Bereitstellung des Produkts auf dem Markt erstellt und, soweit angemessen, mindestens während des Supportzeitraums fortlaufend aktualisiert werden. Der Supportzeitraum spiegelt wider, wie lange das Produkt voraussichtlich genutzt wird, und er beträgt mindestens fünf Jahre, es sei denn, das Produkt wird tatsächlich kürzer genutzt.
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. Der CRA setzt kein festes Prüfintervall. Diese Turnusse sind eine praktische Arbeitsgrundlage:
| 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 |
Jeder Build sollte ein aktuelles SBOM-Artefakt erzeugen, damit der Nachweis mit dem übereinstimmt, was Sie ausliefern. 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. Hier geht es um die Aufbewahrung der Dokumentation. Das ist getrennt von der Pflicht, die Sicherheitsupdates selbst verfügbar zu halten, die ihre eigenen zehn Jahre ab Auslieferung jedes Updates läuft.
Bei einer Produktlinie, die über längere Zeit verkauft wird, bewahren Sie Nachweise für die Versionen und Einheiten auf, 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 |
Die Frist läuft ab der letzten auf dem Markt bereitgestellten Einheit, Dezember 2030 plus zehn Jahre reicht also mindestens bis Dezember 2040, länger, wenn der Supportzeitraum darüber hinausgeht. Bewahren Sie die SBOM an einem sicheren, gesicherten Ort mit Integritätsschutz auf, damit Sie die richtige Version bei einem begründeten Verlangen abrufen und bereitstellen können.
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 Sie 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. Zum Meldeablauf siehe 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 und gehören daher mit Versions- und Kennungsinformationen in die SBOM. Der CRA erwartet außerdem, dass Sie bei den von Ihnen integrierten Drittkomponenten die gebotene Sorgfalt walten lassen, einschließlich quelloffener Software, die Ihnen nicht im Rahmen einer Geschäftstätigkeit bereitgestellt wurde, und dass Sie jede Schwachstelle, die Sie in einer integrierten Komponente finden, einschließlich einer quelloffenen, an deren Wartungsverantwortliche melden.
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 bereitstehen 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 für sich allein 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 Teile, aber Sie schulden weiterhin eine SBOM für das Produkt, wie es auf den Markt gebracht wird. Das bedeutet, Lieferanten-SBOMs mit Ihren eigenen Komponenten und Build-Abhängigkeiten zu einem Nachweis auf Produktebene zu konsolidieren, wie oben unter „Wie viele SBOMs braucht ein Produkt?" beschrieben. Behandeln Sie Lieferanten-SBOMs als Rohmaterial, nicht als fertiges Compliance-Artefakt.