# SBOM für den Cyber Resilience Act

Eine Software-Stückliste (Software Bill of Materials, SBOM) ist die Zutatenliste der Software in Ihrem Produkt. Nach dem CRA ist sie Pflicht - und der einzige praktikable Weg, die Frage "Sind wir betroffen?" zu beantworten, wenn die nächste Schwachstelle veröffentlicht wird.

Source: https://kernwatch.com/de/sbom · Zuletzt aktualisiert: 2026-10-17

## Das Wichtigste in Kürze

- Anhang I des CRA verlangt eine SBOM in einem gängigen, maschinenlesbaren Format, die mindestens die obersten Abhängigkeiten abdeckt.
- CycloneDX (OWASP) und SPDX (ISO/IEC 5962) sind die zwei verbreiteten SBOM-Formate.
- Die SBOM ist Teil der technischen Dokumentation: Sie muss nicht veröffentlicht werden, aber Marktüberwachungsbehörden können sie anfordern.
- Bewährte Praxis: eine SBOM pro unterstütztem Release, in der Build-Pipeline erzeugt und täglich gegen Schwachstellendaten geprüft.

## Was eine SBOM ist

Eine SBOM listet jede Softwarekomponente eines Produkts auf: Open-Source-Bibliotheken, das Betriebssystem, Module von Drittanbietern und Ihre eigenen Pakete. Für jede Komponente enthält sie:

- Name und Version, zum Beispiel `openssl 3.0.13`

- Lieferant

- eine eindeutige Kennung - eine Package-URL (purl) oder CPE

- Lizenz

- von welchen anderen Komponenten sie abhängt

## Was der CRA verlangt

Anhang I des Cyber Resilience Act verpflichtet Hersteller, die in ihren Produkten enthaltenen Schwachstellen und Komponenten zu ermitteln und zu dokumentieren, **unter anderem durch eine Software-Stückliste in einem gängigen und maschinenlesbaren Format, die mindestens die obersten Abhängigkeiten abdeckt**. Die SBOM ist Teil Ihrer technischen Dokumentation; Sie müssen sie nicht veröffentlichen, aber Marktüberwachungsbehörden können sie anfordern.

## CycloneDX und SPDX

Zwei Formate sind verbreitet, beide maschinenlesbar:

- **CycloneDX** (OWASP) - für Sicherheitsanwendungen entwickelt, mit eingebauter Unterstützung für die Bewertung der Ausnutzbarkeit (VEX).

- **SPDX** (Linux Foundation, ISO/IEC 5962) - ursprünglich für Lizenz-Compliance, von vielen Build-Werkzeugen unterstützt.

Die meisten Build-Umgebungen können sie erzeugen: zum Beispiel Syft oder cdxgen für Container und Dateisysteme, die CycloneDX-Plugins für Maven, Gradle und npm und die SPDX-Ausgabe des Yocto Project für Embedded Linux.

## Eine SBOM nützt nur, wenn sie aktuell bleibt

Eine SBOM, die einmal für die Konformitätserklärung erstellt wurde, ist mit dem nächsten Release veraltet. Was in der Praxis hilft:

- eine SBOM pro ausgelieferter Version, erzeugt in der Build-Pipeline;

- jede Komponente täglich gegen neue Schwachstellendaten geprüft;

- eine dokumentierte Entscheidung zu jedem Befund - betroffen, nicht betroffen oder behoben;

- die Unterschiede zwischen Releases auf einen Blick.

## Wie Kernwatch Ihre SBOMs nutzt

- Import von CycloneDX oder SPDX per Upload oder aus der CI mit einem API-Schlüssel.

- Releases vergleichen und sehen, welche Komponenten hinzugekommen, entfernt oder geändert sind.

- Abgleich der Komponenten mit Paketkennung (purl) mit OSV, der CISA-Liste bekannter ausgenutzter Schwachstellen und der EU-Schwachstellendatenbank: täglich in bezahlten Tarifen, wöchentlich im Free-Tarif.

- Bewertungen als VEX zusammen mit der SBOM exportieren, wenn Kunden oder Behörden danach fragen.

## Offizielle Quellen

- [Verordnung (EU) 2024/2847, Anhang I, EUR-Lex](https://eur-lex.europa.eu/eli/reg/2024/2847/oj)
- [CycloneDX-Spezifikation](https://cyclonedx.org/)
- [SPDX-Spezifikation](https://spdx.dev/)
- [OSV-Schwachstellendatenbank](https://osv.dev/)
- [CISA-Katalog bekannter ausgenutzter Schwachstellen](https://www.cisa.gov/known-exploited-vulnerabilities-catalog)