Provetry
ENFRFrühen Zugang anfragen
Kostenloser Check
Frühen Zugang anfragen

Provetry startet im November 2026. Der kostenlose CRA-Check, die Werkzeuge und die Leitfäden sind schon jetzt verfügbar.

SBOM für den Cyber Resilience Act: was zu erstellen ist

7 Min. Lesezeit

Auf dieser Seite
  1. Was der CRA tatsächlich verlangt
  2. CycloneDX oder SPDX?
  3. Was eine brauchbare SBOM enthält
  4. Aktuell halten, sonst ist sie wertlos
  5. Schritt für Schritt für Ihren Stack
  6. Firmware und Geräte
  7. Wie Provetry hilft
  8. Quellen

Eine Software-Stückliste (SBOM) ist die Liste der Komponenten eines Produkts, mit ihren Versionen und ihrer Herkunft. Ab dem 11. Dezember 2027 macht der Cyber Resilience Act sie für jedes Produkt in seinem Anwendungsbereich zur Pflicht. Lange vor diesem Datum ist sie der einzige praktikable Weg, die seit September 2026 geltenden Meldepflichten zu erfüllen: Sie können nicht innerhalb von 24 Stunden sagen, ob eine ausgenutzte Schwachstelle Sie betrifft, wenn Sie nicht wissen, was Sie ausliefern.

Was der CRA tatsächlich verlangt

Anhang I Teil II der Verordnung legt die Anforderungen an den Umgang mit Schwachstellen fest. Die erste verlangt von Herstellern, die in ihren Produkten enthaltenen Schwachstellen und Komponenten zu ermitteln und zu dokumentieren, unter anderem durch eine Software-Stückliste in einem gängigen, maschinenlesbaren Format, die mindestens die Abhängigkeiten der obersten Ebene der Produkte erfasst.

Daraus folgen vier Punkte:

  • Maschinenlesbar, in einem gängigen Format. In der Praxis CycloneDX oder SPDX.
  • Mindestens die Abhängigkeiten der obersten Ebene. Die Pakete, die Ihr Produkt direkt deklariert. Den ganzen Baum aufzulisten, einschließlich transitiver Abhängigkeiten, ist bessere Praxis und macht den Abgleich mit Schwachstellen weit zuverlässiger.
  • Teil Ihrer technischen Dokumentation. Die SBOM gehört zu der Akte, die Sie für die Behörden führen (Anhang VII). Marktüberwachungsbehörden können sie anfordern.
  • Nicht unbedingt öffentlich. Der CRA verlangt nicht, dass Sie Ihre SBOM veröffentlichen. Sie können sie mit Kunden teilen, wenn Sie wollen; viele Geschäftskunden werden danach fragen.

CycloneDX oder SPDX?

Beides ist in Ordnung. CycloneDX (ein OWASP-Projekt, als ECMA-424 standardisiert) wurde mit Blick auf Sicherheit entworfen und transportiert Informationen zu Schwachstellen und Ausnutzbarkeit (VEX) gut. SPDX (Linux Foundation, ISO/IEC 5962) stammt aus der Lizenz-Compliance und wird für Open-Source-Lizenzberichte breit genutzt. Wenn Sie keine Vorliebe haben, beginnen Sie mit CycloneDX und exportieren Sie SPDX, wenn ein Kunde danach fragt. Das BSI verlangt in seiner TR-03183-2 CycloneDX ab 1.6 oder SPDX ab 3.0.1.

Was eine brauchbare SBOM enthält

Für jede Komponente:

  • ihren Namen, ihre Version und ihren Lieferanten;
  • eine eindeutige Kennung, idealerweise eine Package URL (purl) wie pkg:npm/express@4.19.2, damit Schwachstellendatenbanken ohne Raten abgeglichen werden können;
  • einen Hashwert, wenn Sie einen erzeugen können;
  • ihre Beziehung zum Rest (direkte oder transitive Abhängigkeit).

Und für die SBOM selbst: das Produkt und die Version, die sie beschreibt, wann sie erstellt wurde und mit welchem Werkzeug.

Aktuell halten, sonst ist sie wertlos

Eine SBOM beschreibt eine Version. Der häufige Fehler ist ein Dokument, das einmal für ein Audit erstellt und nie wieder angefasst wird. So vermeiden Sie ihn:

  1. Erzeugen Sie sie in Ihrer Build-Pipeline, bei jeder Version, aus den Lock-Dateien und den Container-Images, die Sie tatsächlich ausliefern.
  2. Bewahren Sie die SBOM jeder Version bei der Version auf, damit Sie sagen können, welche Versionen im Feld eine Komponente enthalten.
  3. Gleichen Sie sie täglich mit Schwachstellendaten ab, nicht nur bei der Veröffentlichung: Neue Schwachstellen werden zu Komponenten veröffentlicht, die Sie vor Monaten ausgeliefert haben. Achten Sie auch auf Ausnutzung (CISA KEV, die Europäische Schwachstellendatenbank), denn sie startet die Meldeuhr.
  4. Halten Sie Ihre Entscheidungen fest. Wenn eine verwundbare Komponente vorhanden ist, in Ihrem Produkt aber nicht ausgenutzt werden kann, schreiben Sie es auf (eine VEX-Aussage). Das erspart beim nächsten Mal dieselbe Analyse und dokumentiert Ihre Sorgfalt.

Schritt für Schritt für Ihren Stack

Wie Sie die SBOM erzeugen und was jedes Ökosystem vor ihr verbirgt: npm, pnpm und Yarn, Python, Java, Rust, Go, .NET und Container-Images.

Firmware und Geräte

Bei einem vernetzten Gerät muss die SBOM auch die Firmware abdecken: das Betriebssystem, seine Pakete, den Bootloader und jede Binärdatei von Dritten. Wenn Sie Module von Zulieferern kaufen, fragen Sie jetzt nach deren SBOMs und nehmen Sie diese Forderung in Ihre Einkaufsbedingungen auf. Nach dem CRA liegen die Komponenten, die Sie einbauen, in Ihrer Verantwortung.

Wie Provetry hilft

Provetry erstellt die SBOM jedes Produkts aus Ihrem Repository oder aus einer Datei, bei jeder Version, in CycloneDX und SPDX, überwacht jede Komponente auf neue Schwachstellen und auf Ausnutzung und bewahrt die SBOM jeder Version in Ihrer technischen Akte auf. Der kostenlose Tarif umfasst die SBOM eines Produkts, mit einer wöchentlichen Schwachstellenübersicht.

Dieser Leitfaden ist eine allgemeine Information, keine Rechtsberatung.

Quellen