SBOM erstellen: Anleitung für CRA-Pflicht

Was ist eine Software Bill of Materials?

Eine Software Bill of Materials (SBOM) ist eine vollständige, maschinenlesbare Bestandsliste aller Softwarekomponenten eines Produkts. Sie listet auf, welche Bibliotheken, Pakete und Module in einem Software-Artefakt enthalten sind — einschließlich direkter und transitiver Abhängigkeiten, deren Versionsnummern, Lizenzen und bekannter Schwachstellen.

Das Konzept kommt aus dem Maschinenbau: Wer weiß, welche Teile in einem Gerät verbaut sind, kann schnell handeln, wenn eines davon als fehlerhaft eingestuft wird. Für Software gilt dasselbe. Erst eine vollständige Komponentenliste macht systematisches Schwachstellenmanagement möglich.

Warum ist die SBOM nach CRA Pflicht?

Pflicht nach Anhang I Teil I Nr. 2 CRA, Artikel 13 Abs. 5 und Anhang VII: Der Cyber Resilience Act verpflichtet Hersteller, eine SBOM für ihre Produkte mit digitalen Elementen zu erstellen und aktuell zu halten.¹ Die Pflicht ist direkt an das Schwachstellenmanagement geknüpft: Ohne Kenntnis der eingesetzten Komponenten ist eine systematische Überwachung auf neue CVEs (Common Vulnerabilities and Exposures) nicht möglich.

Konkrete Rechtsgrundlagen:

• Anhang I Teil I Nr. 2: Hersteller müssen eine SBOM erstellen und aktuell halten
• Artikel 13 Abs. 5: Die SBOM muss auf Anfrage an Marktaufsichtsbehörden vorgelegt werden können
• Anhang VII: Die SBOM ist Pflichtbestandteil der technischen Dokumentation

Ein Hersteller von industriellen MQTT-Gateways — also Firmware, die in der Fertigungsautomatisierung zwischen Maschinenebene und Cloud sitzt — ist hier genauso betroffen wie ein IoT-Startup, das embedded-Software für vernetzte Industriesensoren verkauft. Beide müssen für jede ausgelieferte Version nachweisen, welche Komponenten verbaut waren. Kein Auditstapel, keine mündliche Erklärung — eine maschinenlesbare SBOM-Datei.

Die SBOM muss nicht öffentlich zugänglich sein — Hersteller müssen sie aber intern pflegen und auf behördliche Anfrage abrufen können. Für Open-Source-Projekte ist eine öffentliche Bereitstellung gleichwohl empfehlenswert.

Das ist der Punkt, den viele übersehen: Sie müssen heute wissen, was in Ihrer Software steckt — nicht 2027. Eine SBOM, die erst kurz vor dem Stichtag entsteht, ist eine Momentaufnahme ohne Compliance-Geschichte. Prüft die Marktaufsichtsbehörde Ihre Unterlagen, wird sie fragen, seit wann die SBOM gepflegt wird und ob Hersteller sie bei jedem Release aktualisiert haben. Wer 2024 anfängt, hat 2027 eine gut dokumentierte SBOM-Historie. Wer wartet, hat ein Problem.

Zwei Hauptformate: CycloneDX vs. SPDX

Für CRA-konforme SBOMs sind zwei Formate etabliert. Beide werden von den einschlägigen Tools unterstützt und sind grundsätzlich CRA-tauglich. Die Wahl liegt beim Hersteller — beide sind gleichwertig anerkannt.

Empfehlung (nicht vom CRA vorgeschrieben): CycloneDX 1.6 ist für neu aufgesetzte CRA-Compliance-Prozesse die praktischere Wahl, da die Schwachstellen-Kommunikation (VEX — Vulnerability Exploitability eXchange) nativ integriert ist. SPDX macht Sinn, wenn im Haus bereits SPDX-basierte Workflows laufen oder der ISO-Status für Audits relevant ist.²³

Mindest-Inhalte einer CRA-konformen SBOM

Die EU-Kommission orientiert sich bei den Pflichtfeldern an den NTIA-Mindestfeldern sowie an CycloneDX 1.6 und SPDX 2.3.⁴ Eine CRA-konforme SBOM muss für jede Komponente mindestens enthalten:

Darüber hinaus sollte die SBOM auf Metadaten-Ebene enthalten:

• Zeitstempel der Erstellung
• Tool-Angabe (Name und Version des erzeugenden Tools)
• Referenz auf das übergeordnete Artefakt (Komponenten-Name und -Version des analysierten Produkts)

Drei freie Tools — und was sie können

1. Syft (Anchore)

Syft ist ein quelloffenes SBOM-Erzeugungstool von Anchore, das Container-Images, Verzeichnisse und einzelne Artefakte analysiert. Es unterstützt CycloneDX, SPDX und weitere Formate.⁵

Installation:

# macOS
brew install syft

# Linux (Install-Skript)
curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin

SBOM für ein Container-Image erstellen (CycloneDX):

syft <image>:<tag> -o cyclonedx-json > sbom.json

SBOM für ein lokales Verzeichnis (Node.js-Projekt):

syft dir:./mein-projekt -o cyclonedx-json > sbom.json

Nützliche Optionen:

• -o spdx-json — SPDX-Format statt CycloneDX
• --scope all-layers — alle Layer eines Container-Images scannen
• --file sbom.json — statt stdout in Datei schreiben

Einschränkung (nicht vom Tool verschuldet): Syft analysiert, was es sieht. Wenn der Build-Prozess Abhängigkeiten nicht vollständig ins Artefakt einbezieht — etwa bei Monorepos mit separaten Workspaces — entstehen Lücken. Prüfen Sie das Ergebnis gegen Ihre package-lock.json oder pnpm-lock.yaml.

2. Trivy (Aqua Security)

Trivy ist ein umfassendes Security-Scanner-Tool, das neben der SBOM-Erzeugung auch direkt bekannte Schwachstellen (CVEs) meldet. Es ist besonders geeignet, wenn SBOM-Erstellung und Schwachstellen-Scan in einem Schritt erfolgen sollen.⁶

Installation:

# macOS
brew install trivy

# Docker
docker run --rm aquasec/trivy --version

SBOM für ein Container-Image (CycloneDX):

trivy image --format cyclonedx --output sbom.cyclonedx <image>:<tag>

SBOM für ein lokales Dateisystem:

trivy fs --format cyclonedx --output sbom.json ./mein-projekt

Kombinierter Scan (SBOM + CVE-Report):

trivy image --format cyclonedx --output sbom.json <image>
trivy sbom sbom.json   # Schwachstellen-Scan gegen die erzeugte SBOM

3. cdxgen (CycloneDX)

cdxgen ist ein offizielles Tool des CycloneDX-Projekts und beherrscht über 25 Sprachökosysteme direkt — darunter Java (Maven/Gradle), JavaScript/TypeScript (npm/yarn/pnpm), Python (pip/poetry), Go, Rust, .NET und mehr. Es wertet direkt die Paketmanager-Metadaten aus statt Binärartefakte zu scannen, was die Ergebnisse bei Quellcode-Projekten präziser macht.⁷

Installation:

npm install -g @cyclonedx/cdxgen

SBOM für ein Node.js-Projekt:

cdxgen -o sbom.json ./mein-projekt

Für ein Java-Projekt:

cdxgen -t java -o sbom.json ./mein-java-projekt

Mit Lizenz-Scan:

cdxgen --generate-key-and-sign -o sbom.json ./mein-projekt

Wann cdxgen besonders geeignet ist: Bei Projekten mit mehreren Sprachökosystemen im selben Repo (z. B. Rust-Backend + TypeScript-Frontend) ist cdxgen oft vollständiger als Syft, weil es Paketmanager-Metadaten direkt auswertet. Für polyglotte Monorepos ist es die erste Empfehlung.

In der Praxis erleben wir: Ein Hersteller von embedded-Software für Heizungssteuerungen — typischerweise ein Rust-Backend mit einem kleinen TypeScript-Frontend für die Konfigurationsoberfläche — unterschätzt hier oft den Scope. Zwei Ökosysteme, zwei getrennte Abhängigkeitsgraphen, eine SBOM. cdxgen löst das in einem Schritt. Syft braucht Nacharbeit.

Die SBOM-Lücke: Was Tools nicht automatisch lösen

SBOM-Tools sind gut. Aber die eigentliche Herausforderung liegt nicht im Tool, sondern in der Vollständigkeit des Inputs. Typische Lückenquellen:

Monorepos mit 50+ Packages: Bei großen Monorepos kann ein Workspace vom Tool falsch zugeordnet werden. Ergebnis: Eine valide SBOM, die aber nicht alle Teile des Produkts abdeckt. Empfehlung: SBOM pro Workspace erzeugen und anschließend zusammenführen.

Native Binaries und System-Abhängigkeiten: Wenn ein Produkt native Node-Addons, Rust-Binaries oder System-Bibliotheken (z. B. OpenSSL, libcurl) nutzt, erfassen viele Tools diese nicht automatisch. Hersteller müssen diese manuell ergänzen.

Build-zeitliche Abhängigkeiten vs. Runtime-Abhängigkeiten: devDependencies können im Produktions-Bundle landen, wenn Tree-Shaking nicht greift. Prüfen Sie, ob die SBOM die tatsächlich ausgelieferten Abhängigkeiten widerspiegelt — nicht nur die deklarierten.

Eingebettete Drittanbieter-Bibliotheken: Manche Projekte kopieren Teile von Bibliotheken direkt in den Code (Vendoring). Scanner-Tools erkennen diese nicht als separate Komponenten. Hersteller müssen sie manuell in die SBOM eintragen.

Was viele CRA-Berater nicht sagen: Diese Lücken sind kein Randproblem. Gerade bei industriellen MQTT-Gateways oder Industrie-4.0-Middleware, die über Jahre gewachsen sind, finden sich regelmäßig gevendorte Bibliotheken und native System-Abhängigkeiten, die kein Scanner automatisch aufdeckt. Wer nur einen Tool-Scan abliefert, hat keine vollständige SBOM — er hat eine teilweise.

Ein Maschinenbau-Zulieferer, der eine Industrie-4.0-Middleware für den Shopfloor betreibt, erlebt das regelmäßig: Die Codebasis ist fünf Jahre alt, drei Teams haben daran gearbeitet, und irgendwo im C++-Layer steckt eine gevendorte Version von libexpat aus 2019. Kein Scanner findet das automatisch. Das ist die Arbeit, die vor dem Tool-Scan gemacht werden muss.

Schritt-für-Schritt: SBOM für ein Node.js-Projekt

Das folgende Vorgehen erzeugt eine CRA-konforme SBOM für ein typisches Node.js-Projekt mit npm oder pnpm.

Schritt 1 — Voraussetzungen prüfen

Sicherstellen, dass package-lock.json (npm) oder pnpm-lock.yaml (pnpm) aktuell ist und alle installierten Abhängigkeiten widerspiegelt:

npm ci        # saubere Installation aus Lockfile
# oder
pnpm install --frozen-lockfile

Schritt 2 — cdxgen installieren und SBOM erzeugen

npm install -g @cyclonedx/cdxgen
cdxgen -o sbom.json .

Das erzeugt sbom.json im CycloneDX 1.6 JSON-Format im aktuellen Verzeichnis.

Schritt 3 — SBOM validieren

# Validierung mit dem offiziellen CycloneDX CLI-Tool
npm install -g @cyclonedx/cyclonedx-cli
cyclonedx validate --input-file sbom.json --input-version v1_6

Ein valides SBOM gibt Validation successful aus. Fehler deuten auf fehlende Pflichtfelder hin.

Schritt 4 — Schwachstellen prüfen

# Trivy nutzt die erzeugte SBOM für einen CVE-Scan
trivy sbom sbom.json

Alle gemeldeten CVEs mit CVSS-Score ≥ 7 sind kritisch und erfordern eine Maßnahme (Update, Mitigations-Dokumentation oder VEX-Statement).

Schritt 5 — SBOM in die technische Dokumentation aufnehmen

Die erzeugte sbom.json wird versioniert (z. B. sbom-v1.2.3.json) und mit der technischen Dokumentation des Produkts abgelegt. Die Aufbewahrungsfrist beträgt mindestens 10 Jahre nach Inverkehrbringen.

SBOM aufbewahren und aktualisieren

Eine einmal erstellte SBOM ist nur eine Momentaufnahme. Das klingt nach wenig. Ist es aber nicht. Pflicht nach Artikel 13 Abs. 5 und Anhang VII CRA: Hersteller müssen die SBOM über den gesamten Unterstützungszeitraum aktuell halten.

Wann muss die SBOM aktualisiert werden?

• Bei jeder neuen Software-Version (Release oder Update)
• Nach Integration einer neuen Abhängigkeit oder Aktualisierung einer bestehenden
• Nach Behebung einer Schwachstelle durch Abhängigkeits-Update
• Bei wesentlichen Änderungen an der Produktarchitektur

Empfohlene Integration in CI/CD-Pipeline (GitHub Actions-Beispiel):

- name: SBOM erzeugen
  run: |
    npm install -g @cyclonedx/cdxgen
    cdxgen -o sbom-${{ github.ref_name }}.json .

- name: SBOM als Artefakt sichern
  uses: actions/upload-artifact@v4
  with:
    name: sbom-${{ github.ref_name }}
    path: sbom-${{ github.ref_name }}.json
    retention-days: 3650   # 10 Jahre

Aufbewahrungsort: Die SBOM sollte zusammen mit der technischen Dokumentation aufbewahrt werden — nicht nur im CI/CD-System, da Build-Artefakte dort häufig nach kurzer Zeit gelöscht werden. Geeignet sind ein dediziertes Artefakt-Repository (z. B. Nexus, Artifactory), ein versioniertes Git-Repository oder verschlüsselter Langzeit-Speicher.

Konkret bedeutet das: Ein IoT-Startup, das embedded-Software für vernetzte Industriesensoren verkauft, muss für jede ausgelieferte Firmware-Version eine archivierte SBOM nachweisen können — nicht nur für die aktuelle. 10 Jahre. Das ist der Rahmen, den Anhang VII setzt. Wer das unterschätzt und nur die aktuelle SBOM pflegt, wird bei einer Marktaufsichtsprüfung nicht bestehen.

Verhältnis zu anderen CRA-Dokumenten

Die SBOM ist kein isoliertes Dokument, sondern Teil eines größeren Compliance-Pakets:

• Risikoanalyse: Baut auf der SBOM auf — ohne Komponentenliste keine vollständige Bedrohungsanalyse
• Schwachstellen-Management-Prozess: Nutzt die SBOM für kontinuierliches CVE-Monitoring
• Technische Dokumentation (Anhang VII): Enthält die SBOM als Pflichtbestandteil
• Konformitätserklärung: Verweist auf die erfüllten Anforderungen aus Anhang I, zu denen die SBOM-Pflicht gehört

Mehr zu den übergreifenden Pflichten lesen Sie unter CRA-Pflichten für Hersteller. Welche Risikoklasse für Ihr Produkt gilt und welche Konformitätsbewertung das erfordert, erfahren Sie unter CRA Risikoklassen erklärt.

Starten Sie jetzt den kostenlosen CRA-Check und erfahren Sie, welche SBOM-Pflichten konkret für Ihr Produkt gelten — und ob Sie anschließend mit dem Evidence Pack in wenigen Wochen vollständig dokumentiert sein können.

Quellen

1. EU-Verordnung 2024/2847 (Cyber Resilience Act), Anhang I Teil I Nr. 2, Artikel 13 Abs. 5, Anhang VII: https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=OJ:L_202402847
2. CycloneDX Spezifikation 1.6, OASIS-Standard 2024: https://cyclonedx.org/specification/overview/
3. SPDX Spezifikation 2.3, Linux Foundation / ISO/IEC 5962:2021: https://spdx.dev/specifications/
4. NTIA — The Minimum Elements For a Software Bill of Materials (SBOM): https://www.ntia.doc.gov/report/2021/minimum-elements-software-bill-materials-sbom
5. Anchore Syft — Open Source SBOM Tool: https://github.com/anchore/syft
6. Aqua Security Trivy — Vulnerability and SBOM Scanner: https://github.com/aquasecurity/trivy
7. CycloneDX cdxgen — Multi-Language SBOM Generator: https://github.com/CycloneDX/cdxgen