SBOM: was der CRA verlangt und wie Sie die Stückliste aufbauen

Felder und Formate legt der CRA nicht fest. Dieser Leitfaden zeigt, was die Verordnung sagt, was die BSI TR-03183-2 ergänzt und wie Sie die Stückliste in sechs Schritten aufbauen, auch für Firmware und Steuerungen.

Was der CRA festlegt

Für Produkte, die vor dem 11.12.2027 in Verkehr gebracht wurden, gilt die Pflicht nur, wenn sie danach wesentlich geändert werden (Art. 69 Abs. 2).

Was die BSI TR-03183-2 ergänzt

Das BSI hat mit der Technischen Richtlinie TR-03183-2 konkrete Anforderungen an SBOMs beschrieben, aktuell in Version 2.1.0 vom 20.08.2025. Die Richtlinie ist keine harmonisierte Norm zum CRA. Sie zeigt aber im Detail, was in eine SBOM gehört, und geht deutlich über das gesetzliche Minimum hinaus.

Diese Felder gehören hinein

Die Richtlinie unterscheidet Pflichtfelder, Zusatzfelder und optionale Felder:

• Für die SBOM selbst. Ersteller mit E-Mail-Adresse oder URL und ein Zeitstempel, wenn vorhanden auch die SBOM-URI.
• Für jede Komponente. Ersteller, Name, Version, Dateiname, Abhängigkeiten, Lizenzen und ein SHA-512-Hash der auslieferbaren Komponente.
• Drei Eigenschaften je Komponente. Ist sie ausführbar, ist sie ein Archiv, und ist sie strukturiert?
• Wenn vorhanden. Adresse des Quellcodes, Adresse der auslieferbaren Form, weitere Kennungen wie CPE oder purl und die Originallizenzen.
• Optional. Etwa die wirksame Lizenz, ein Hash des Quellcodes und die Adresse der security.txt des Erstellers.

CPE und purl sind in der Praxis besonders wichtig. Über diese Kennungen finden Sie die Komponente in Schwachstellendatenbanken wieder.

SBOM, VEX und CSAF

Drei Begriffe, drei Aufgaben. Die SBOM bleibt für eine Softwareversion stabil, die Lage bei den Schwachstellen ändert sich dagegen laufend. Darum gehören sie getrennt.

• SBOM. Sie sagt, woraus eine Version besteht.
• VEX. Es sagt, ob eine bekannte Schwachstelle Ihr Produkt tatsächlich betrifft, zum Beispiel „nicht betroffen, Code wird nicht erreicht“.
• CSAF. Das ist das maschinenlesbare Format für Sicherheitshinweise. Die BSI TR-03183-2 empfiehlt es für Schwachstelleninformationen und nennt VEX als ein Profil davon.

In sechs Schritten zur SBOM

1. Produkt und Lieferumfang abgrenzen. Legen Sie je Produkt fest, was Sie ausliefern: Firmware, Bediensoftware, App, Bootloader. Gehört eine Cloud-Funktion zum Produkt, nehmen Sie diese in die Betrachtung auf.
2. Stückliste im Build erzeugen. Die Stückliste entsteht am besten automatisch im Build, nicht von Hand. Die BSI TR verlangt dieselben Informationen, die im Build verfügbar sind.
3. Zulieferer einbeziehen. Fordern Sie für zugekaufte Software und Module eine SBOM an. Fehlt sie, kann eine Binäranalyse helfen, und die Lücke gehört dokumentiert.
4. Prüfen. Validieren Sie Format und Pflichtangaben vor der Freigabe. ENISA empfiehlt zusätzlich, auch die Kennungen der Komponenten zu prüfen und die SBOM zu signieren.
5. Je Version ablegen. Halten Sie zu jeder ausgelieferten Version genau eine SBOM fest. Ändert sich eine Komponente, ändert sich auch die Version.
6. Laufend abgleichen. Vergleichen Sie die Komponenten regelmäßig mit Schwachstellendaten. Erst dieser Schritt macht die Liste im Alltag nützlich.

Besonderheiten bei Firmware und Steuerungen

In der Industrie ist die Stückliste selten so einfach wie bei einer reinen App. Vier Fälle kommen häufig vor:

• Eingebettetes Linux. Build-Systeme kennen die Pakete oft schon. Nutzen Sie diese Daten, statt die fertige Firmware nachträglich zu analysieren.
• Zugekaufte Module. Funkmodule oder Laufzeitsysteme kommen häufig als Binärdatei. Regeln Sie die Lieferung einer SBOM im Einkauf.
• Mehrere Prozessoren. Hat ein Gerät mehrere Firmware-Stände, muss die Stückliste alle ausgelieferten Teile abdecken.
• Lange Laufzeiten. Die SBOM alter Versionen brauchen Sie, solange diese im Feld oder im Support sind.

Das Beispiel ist erfunden: Ein Steuerungshersteller erfährt von einer Lücke in einer Kryptobibliothek. Mit Stücklisten je Version sieht er in Minuten, dass nur Firmware 2.3 und 2.4 betroffen sind. Ohne sie fragt er bei Entwicklung und Zulieferern nach.

Typische Fehler

• Nur die erste Ebene. Das erfüllt das gesetzliche Minimum, hilft aber wenig, wenn die Lücke in einer tief eingebundenen Bibliothek steckt.
• Eine SBOM für alle Versionen. Dann lässt sich nicht sagen, welche ausgelieferte Version betroffen ist.
• Excel als Dauerlösung. Eine Tabelle hilft für den Anfang, ist aber kein gängiges SBOM-Format und veraltet beim nächsten Release.
• Fehlende Kennungen. Ohne CPE oder purl läuft der Abgleich ins Leere oder liefert falsche Treffer.
• Schwachstellen in der SBOM. Die BSI TR schließt das aus, weil die SBOM sonst bei jeder neuen Meldung neu verteilt werden müsste.

Die SBOM in Complass

Sie erzeugen die SBOM weiter in Ihrem Build. Complass verbindet sie mit Version, Schwachstellen und Nachweis:

• Importieren. Sie laden CycloneDX, SPDX oder eine Excel- oder CSV-Vorlage hoch und sehen vor dem Übernehmen eine Vorschau.
• Stände festhalten. Je Auslieferung speichern Sie einen unveränderlichen Stand mit Prüfsumme und vergleichen zwei Stände miteinander.
• Exportieren. Sie exportieren CycloneDX 1.6 als JSON oder XML, SPDX 2.3, SPDX 3.0.1 und CycloneDX-VEX. Fehlt im Portal eine Angabe, lässt der SPDX-3.0.1-Export sie weg, statt sie zu erfinden.
• Abgleichen. Komponenten mit CPE laufen im Abgleich mit öffentlichen Schwachstellendaten, ohne dass Ihre Angaben das Portal verlassen.
• Mit der Produktakte verbinden. Der gespeicherte Stand gehört zur Produktversion und zählt in deren Vollständigkeitsprüfung.
• Mit Kunden austauschen. Über den Lieferketten-Austausch geben Sie SBOM und VEX an Kunden frei und übernehmen die SBOM Ihrer Lieferanten.

Checkliste

• Je Produkt ist der Lieferumfang beschrieben.
• Die SBOM entsteht automatisch im Build.
• Format und Version sind festgelegt, zum Beispiel CycloneDX 1.6.
• Die Abhängigkeiten sind über die oberste Ebene hinaus aufgelöst.
• Komponenten tragen CPE oder purl.
• Lieferanten liefern zugekaufte Software mit SBOM.
• Je ausgelieferter Version gibt es genau einen gespeicherten Stand.
• Die SBOM ist Teil der technischen Dokumentation.
• Komponenten werden laufend mit Schwachstellendaten abgeglichen.
• Es ist entschieden, ob und wie Kunden die SBOM erhalten.

Häufige Fragen

Müssen wir die SBOM veröffentlichen?

Nein. Der CRA verlangt keine Veröffentlichung. Die SBOM gehört zur technischen Dokumentation, die Behörde kann sie auf begründetes Verlangen anfordern (Anhang VII Nr. 8). Geben Sie sie freiwillig an Nutzer weiter, nennen Sie den Abrufort (Anhang II Nr. 9).

Reichen die direkten Abhängigkeiten?

Für den CRA reichen nach dem Wortlaut die obersten Abhängigkeiten. Die BSI TR-03183-2 geht weiter und verlangt die rekursive Auflösung im Lieferumfang. Für den Umgang mit Schwachstellen empfehlen wir die größere Tiefe.

CycloneDX oder SPDX?

Beide sind gängig, und die BSI TR akzeptiert beide ab den Versionen 1.6 und 3.0.1. Entscheiden Sie danach, was Ihre Werkzeuge und Kunden lesen können. Complass liest und exportiert beide Formate.

Gilt die Pflicht auch für reine Hardware?

Die SBOM betrifft die Softwareelemente eines Produkts (Art. 3 Nr. 39). Enthält Ihre Hardware Firmware, gehört diese hinein.

In einer Demo zeigen wir Ihnen den Weg von der Build-Datei zum Abgleich und zur Freigabe an Kunden.

Demo anfragen 14 Tage testen

Weiterlesen

• Whitepaper „Cyber Resilience Act für Hersteller von Hardware und Software“
• Whitepaper „Asset-Inventar, SBOM und Schwachstellenmanagement: wissen, was läuft, und belegen, was Sie tun“
• Whitepaper „Secure Development für Hersteller“
• Cyber Resilience Act in Complass: von der Anwendbarkeit bis zur CE-Kennzeichnung
• Vulnerability-Management: Schwachstellen finden und abarbeiten
• Asset-Management: Inventar, Software und SBOM

Keine Rechtsberatung. Dieser Leitfaden gibt einen allgemeinen Überblick und ersetzt nicht die Prüfung im Einzelfall. Die BSI TR-03183-2 und die ENISA-Empfehlungen sind Orientierung und ersetzen nicht die Verordnung.