SBOM erstellen: CRA-Anforderung mit CycloneDX und SPDX

Der Cyber Resilience Act verpflichtet Hersteller, eine Software-Stückliste (SBOM) in einem gängigen, maschinenlesbaren Format zu erstellen, die mindestens die obersten Abhängigkeiten des Produkts abdeckt. In der Praxis heißt das: CycloneDX oder SPDX, automatisch bei jedem Build erzeugt und pro ausgelieferter Version archiviert.

Veröffentlichen müssen Sie die SBOM nicht – sie gehört zur technischen Dokumentation und ist Marktüberwachungsbehörden auf Verlangen vorzulegen. Ihr eigentlicher Wert liegt woanders: Ohne SBOM können Sie im Ernstfall nicht schnell beantworten, ob eine ausgenutzte Komponente in Ihren Produkten steckt – und genau das verlangt die CRA-Meldepflicht ab September 2026.

Was verlangt der CRA?

• Annex I Teil II Nr. 1: Hersteller identifizieren und dokumentieren Schwachstellen und Komponenten, u. a. durch eine SBOM in einem gängigen, maschinenlesbaren Format, die mindestens die Top-Level-Abhängigkeiten umfasst.
• Annex VII: Die SBOM ist Teil der technischen Dokumentation, sofern verfügbar.
• Durchführungsrechtsakte: Die Kommission kann Format und Elemente der SBOM näher festlegen.

Top-Level-Abhängigkeiten sind das Minimum. Für ein belastbares Schwachstellenmanagement empfiehlt sich die vollständige transitive Abhängigkeitskette – die meisten Lücken stecken in indirekten Paketen.

Warum das Thema drängt

Über tausend Komponenten pro Anwendung lassen sich nicht manuell pflegen. Eine SBOM, die nur einmal vor dem Release per Hand erstellt wird, ist nach dem nächsten Dependency-Update veraltet.

Formate: CycloneDX vs. SPDX

Beide Formate sind CRA-tauglich. Wenn Ihr Fokus auf Schwachstellenmanagement liegt, ist CycloneDX meist der pragmatischere Start. Wichtiger als die Wahl ist Konsistenz: ein Format, eine Pipeline, eine Ablage.

BSI TR-03183-2: Mindestfelder

Die Technische Richtlinie TR-03183 des BSI konkretisiert die CRA-Anforderungen und besteht aus drei Teilen; Teil 2 behandelt SBOMs. Sie erwartet CycloneDX oder SPDX in aktuellen Versionen und definiert Pflichtfelder, u. a.:

• Ersteller der SBOM und Zeitstempel
• je Komponente: Ersteller, Name, Version, Abhängigkeiten
• Lizenzinformationen
• Hashwert der ausgelieferten Komponente

Die TR ist rechtlich nicht verbindlich, aber die beste verfügbare Orientierung, solange die EU keine Details festgelegt hat. Prüfen Sie die aktuelle Version direkt beim BSI.

SBOM im CI/CD

GitHub Actions und andere Pipelines

1. Generator im Build-Job ausführen (z. B. Syft oder cdxgen) – nach dem Auflösen der Abhängigkeiten, damit Lockfiles berücksichtigt werden.
2. SBOM als Build-Artefakt mit Versions- und Commit-Bezug speichern.
3. Für Releases: SBOM signieren und unveränderlich archivieren – mindestens für die Aufbewahrungsdauer der technischen Dokumentation (10 Jahre oder Supportzeitraum, je nachdem was länger ist).

Container-Images und Firmware

Bei Containern gehört die SBOM zum Image, nicht nur zum Quellcode: Basis-Image und Systempakete sind oft die größte Schwachstellenquelle. Bei Firmware sollten Sie Toolchain-Komponenten, Bootloader und Drittanbieter-Binärdateien einschließen, auch wenn diese nicht aus einem Paketmanager stammen.

Von der SBOM zum Schwachstellenabgleich

Eine SBOM wird erst nützlich, wenn sie kontinuierlich gegen Schwachstellendatenbanken (z. B. OSV, NVD) und Exploit-Signale abgeglichen wird. Ergänzen Sie VEX-Aussagen (Vulnerability Exploitability eXchange), um zu dokumentieren, warum eine Schwachstelle in Ihrem Produkt nicht ausnutzbar ist – das spart Diskussionen mit Kunden und Behörden.

Häufige Fehler

• SBOM aus dem Quellcode statt aus dem ausgelieferten Artefakt.
• Keine Versionierung – im Meldefall weiß niemand, welche SBOM zu welcher Kundeninstallation gehört.
• Nur Top-Level-Abhängigkeiten, obwohl die Lücken transitiv sind.
• Handgeschriebene Komponenten und vendorte Bibliotheken fehlen.

Schritt für Schritt zur ersten SBOM

1. Artefakt wählen: Starten Sie mit dem Produkt, das die meisten Kunden nutzt, und dem Artefakt, das tatsächlich ausgeliefert wird – Installer, Container-Image oder Firmware-Image.
2. Generator testen: Lassen Sie ein Werkzeug wie Syft oder cdxgen lokal über das Artefakt laufen und prüfen Sie die Ausgabe stichprobenartig gegen Ihre Lockfiles.
3. Lücken schließen: Ergänzen Sie Komponenten, die der Generator nicht erkennt, etwa kopierte Bibliotheken oder Binärdateien von Zulieferern.
4. In die Pipeline übernehmen: Erzeugen Sie die SBOM bei jedem Release-Build automatisch und legen Sie sie zusammen mit dem Artefakt ab.
5. Abgleich einrichten: Verbinden Sie die SBOM mit einem Schwachstellenscanner und definieren Sie, wer Treffer bewertet.

Beispiele aus der Praxis

Web-Agentur mit vielen Kundenprojekten

Eine Agentur betreut zahlreiche Node.js- und PHP-Projekte. Statt pro Projekt ein eigenes Vorgehen zu bauen, definiert sie einen gemeinsamen Pipeline-Baustein, der bei jedem Deployment eine CycloneDX-SBOM erzeugt und sie dem Kunden als Teil der Release-Unterlagen übergibt. So kann jeder Kunde als Hersteller die SBOM in seine technische Dokumentation übernehmen.

Gerätehersteller mit Embedded Linux

Ein Hersteller von Industrie-Gateways baut Firmware mit einem Embedded-Linux-Build-System. Hier stammen viele Komponenten aus dem Build-System selbst. Sinnvoll ist, die SBOM direkt aus dem Build-Prozess zu erzeugen, statt das fertige Image nachträglich zu analysieren – das liefert genauere Versionsangaben.

Automatisch mit Nuowei

Nuowei (Beta, Launch November 2026) erzeugt bei jedem Commit eine SBOM, versioniert sie je Release und gleicht sie laufend mit Schwachstellen ab. Mehr dazu auf unserer SBOM-Seite – dort können Sie sich auch auf die Warteliste setzen.