SBOM für den CRA erstellen: Tools, Formate, CI/CD

Der CRA verlangt eine Software-Stückliste (SBOM). Jeder Wettbewerberartikel sagt Ihnen das. Keiner zeigt Ihnen die Erstellung Schritt für Schritt.

Dieser Leitfaden behandelt Open-Source-Tools, Formatauswahl und CI/CD-Integration ohne Vendor-Lock-in.

Was der CRA tatsächlich verlangt

Beginnen wir mit dem, was die Verordnung sagt. Anhang I, Teil II des CRA verlangt von Herstellern:

„Schwachstellen und Komponenten der Produkte mit digitalen Elementen ermitteln und dokumentieren, u. a. durch Erstellung einer Software-Stückliste in einem gängigen maschinenlesbaren Format, aus der zumindest die obersten Abhängigkeiten der Produkte hervorgehen"

Kernpunkte:

• Maschinenlesbares Format: Kein PDF, keine Tabellenkalkulation, sondern strukturierte Daten
• Mindestens Abhängigkeiten der obersten Ebene: Der Mindestumfang, obwohl mehr besser ist
• Nicht öffentlich erforderlich: Wird Behörden auf Anfrage bereitgestellt
• Muss aktualisiert werden: Mit jeder Veröffentlichung, jedem Patch oder jeder Komponentenänderung

Der CRA schreibt kein spezifisches Format vor, aber Standardisierungsbemühungen weisen klar auf CycloneDX und SPDX hin.

Die SBOM ist Teil der CRA technischen Dokumentation gemäß Anhang VII. Hersteller müssen diese Dokumentation vor dem Inverkehrbringen eines Produkts erstellen und sie Marktüberwachungsbehörden mindestens 10 Jahre nach dem Inverkehrbringen oder für die Dauer des Supportzeitraums zur Verfügung halten, je nachdem, welcher Zeitraum länger ist (Artikel 13 Absatz 13). Eine lokal gespeicherte SBOM ohne Bezug zu einem konkreten Produkt-Release erfüllt diese Anforderung nicht. Sie muss abrufbar, versioniert und an die beschriebene Produktversion geknüpft sein.

Formatauswahl: CycloneDX vs. SPDX

Zwei Formate dominieren die SBOM-Landschaft. Beide sind für die CRA-Compliance akzeptabel.

CycloneDX

Herkunft: OWASP-Projekt, sicherheitsorientiert Aktuelle Version: 1.6 (1.4+ für CRA empfohlen) Optimal für: Sicherheits- und Schwachstellenmanagement

Stärken:

• Native VEX-Unterstützung (Vulnerability Exploitability eXchange)
• Für Sicherheitsanwendungsfälle konzipiert
• Leichtere Spezifikation, einfacher umzusetzen
• Starkes Tool-Ökosystem
• Direkte CVE/Schwachstellen-Verknüpfung

JSON-Beispiel:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "version": 1,
  "components": [
    {
      "type": "library",
      "name": "lodash",
      "version": "4.17.21",
      "purl": "pkg:npm/lodash@4.17.21",
      "hashes": [
        {
          "alg": "SHA-256",
          "content": "cc6d..."
        }
      ],
      "licenses": [
        {
          "license": {
            "id": "MIT"
          }
        }
      ]
    }
  ]
}

SPDX

Herkunft: Linux Foundation, lizenzorientiert Aktuelle Version: 2.3; ISO/IEC 5962:2021 standardisierte SPDX 2.2.1 Optimal für: Lizenz-Compliance und rechtliche Prüfung

Stärken:

• ISO-Internationaler Standard
• Umfassende Lizenzausdruckssyntax
• Stark im Open-Source-Compliance-Kontext
• Längere Erfolgsbilanz
• Besser für komplexe Lizenzierungsszenarien

JSON-Beispiel:

{
  "spdxVersion": "SPDX-2.3",
  "dataLicense": "CC0-1.0",
  "SPDXID": "SPDXRef-DOCUMENT",
  "name": "my-application",
  "packages": [
    {
      "SPDXID": "SPDXRef-Package-lodash",
      "name": "lodash",
      "versionInfo": "4.17.21",
      "downloadLocation": "https://registry.npmjs.org/lodash/-/lodash-4.17.21.tgz",
      "licenseConcluded": "MIT",
      "checksums": [
        {
          "algorithm": "SHA256",
          "checksumValue": "cc6d..."
        }
      ]
    }
  ]
}

Welches Format wählen?

Für CRA-Compliance funktioniert jedes Format. Wählen Sie eines und bleiben Sie konsistent.

Open-Source SBOM-Erstellungstools

Kein Vendor-Lock-in erforderlich. Diese Tools sind kostenlos, Open-Source und produktionsreif.

Syft (Anchore)

Optimal für: Container-Images, Dateisysteme, Archive Lizenz: Apache 2.0 Ausgabeformate: CycloneDX, SPDX, Syft JSON

Installation:

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

# Homebrew
brew install syft

# Docker
docker pull anchore/syft

Verwendungsbeispiele:

# Container-Image scannen
syft alpine:latest -o cyclonedx-json > sbom.cdx.json

# Verzeichnis scannen
syft dir:/path/to/project -o cyclonedx-json > sbom.cdx.json

# Archiv scannen
syft /path/to/archive.tar.gz -o spdx-json > sbom.spdx.json

# Mit spezifischen Katalogisierern scannen (z.B. nur Python)
syft dir:. -o cyclonedx-json --select-catalogers python

Unterstützte Ökosysteme: Python, Node.js, Ruby, Java, Go, Rust, PHP, .NET und mehr.

Trivy (Aqua Security)

Optimal für: Container-Images mit integriertem Schwachstellen-Kontext Lizenz: Apache 2.0 Ausgabeformate: CycloneDX, SPDX, plus Schwachstellenberichte

Installation:

# Linux (Debian/Ubuntu)
sudo apt-get install trivy

# macOS
brew install trivy

# Docker
docker pull aquasec/trivy

Verwendungsbeispiele:

# SBOM aus Container-Image erstellen
trivy image --format cyclonedx --output sbom.cdx.json alpine:latest

# SBOM aus Dateisystem erstellen
trivy fs --format cyclonedx --output sbom.cdx.json /path/to/project

# SBOM mit Schwachstellen-Info erstellen
trivy image --format cyclonedx --output sbom.cdx.json \
  --scanners vuln nginx:latest

Vorteil: Trivy kann SBOMs erstellen und in einem Durchgang nach Schwachstellen scannen.

cdxgen (CycloneDX)

Optimal für: Quellcode-Analyse über viele Sprachen hinweg Lizenz: Apache 2.0 Ausgabeformat: CycloneDX

Installation:

# npm (erfordert Node.js)
npm install -g @cyclonedx/cdxgen

# Docker
docker pull ghcr.io/cyclonedx/cdxgen

Verwendungsbeispiele:

# Aktuelles Verzeichnis scannen
cdxgen -o sbom.json

# Spezifischen Projekttyp scannen
cdxgen -t python -o sbom.json

# Mit tiefgreifender Abhängigkeitsauflösung scannen
cdxgen --deep -o sbom.json

# Spezifisches Verzeichnis scannen
cdxgen -o sbom.json /path/to/project

Unterstützte Sprachen: JavaScript, Python, Java, Go, Rust, PHP, Ruby, .NET, C/C++ und mehr.

Tool-Vergleich

Empfehlung: Beginnen Sie mit Syft für die meisten Anwendungsfälle. Fügen Sie Trivy hinzu, wenn Sie integriertes Schwachstellen-Scanning benötigen. Verwenden Sie cdxgen für komplexe Quellcode-Projekte.

Firmware und Embedded-Geräte

Die oben genannten Tools eignen sich gut für Container und Paketmanager. Bei Firmware und Embedded-Geräten, dem primären CRA-Ziel, ist der Ansatz ein anderer.

Firmware-Images sind binäre Blobs, keine Paket-Registries. Der erste Schritt ist die Extraktion des Dateisystems:

# Dateisystem aus Firmware-Image extrahieren
binwalk -Me firmware.bin

# Syft auf dem extrahierten Dateisystem ausführen
syft dir:_firmware.bin.extracted/squashfs-root -o cyclonedx-json > sbom.cdx.json

Verwenden Sie binwalk -Me (rekursive Extraktion) statt -e bei verschachtelten oder komprimierten Images. Die Abdeckung ist geringer als bei Container-Images. Gestripte Binaries verlieren Symbol-Informationen, und Syft erkennt möglicherweise nicht alle Komponenten.

Für die Analyse auf Binärebene bieten BLint, cve-bin-tool und EMBA tiefere Einblicke. Proprietäre SDKs und Closed-Source-Bibliotheken in Firmware erfordern in der Regel manuelle SBOM-Einträge. Dokumentieren Sie Anbieter, Version und Quell-URL.

CI/CD-Integration

Manuelle SBOM-Erstellung skaliert nicht. Integrieren Sie sie in Ihre Build-Pipeline.

GitHub Actions

name: SBOM-Erstellung

on:
  push:
    branches: [main]
  release:
    types: [published]

jobs:
  sbom:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      id-token: write   # erforderlich für Cosign Keyless-Signierung
    steps:
      - name: Code auschecken
        uses: actions/checkout@v4

      - name: Container-Image bauen
        run: |
          docker build -t myapp:${{ github.sha }} .

      - name: Syft installieren
        run: |
          curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin

      - name: SBOM aus gebautem Image erstellen
        run: |
          syft myapp:${{ github.sha }} -o cyclonedx-json > sbom.cdx.json

      - name: Cosign installieren
        uses: sigstore/cosign-installer@v3

      - name: SBOM signieren (Keyless)
        run: |
          cosign sign-blob sbom.cdx.json --bundle sbom.cdx.json.sigstore.json --yes

      - name: SBOM und Signatur als Artefakte hochladen
        uses: actions/upload-artifact@v4
        with:
          name: sbom
          path: |
            sbom.cdx.json
            sbom.cdx.json.sigstore.json
          retention-days: 90

      # Optional: Zu CRA Evidence für langfristige Compliance-Speicherung hochladen
      - name: Zu CRA Evidence hochladen
        if: github.event_name == 'release'
        env:
          CRA_EVIDENCE_TOKEN: ${{ secrets.CRA_EVIDENCE_TOKEN }}
        run: |
          curl -X POST https://api.craevidence.com/api/v1/ci/sbom \
            -H "Authorization: Bearer $CRA_EVIDENCE_TOKEN" \
            -F "file=@sbom.cdx.json" \
            -F "product_id=${{ vars.PRODUCT_ID }}" \
            -F "version=${{ github.ref_name }}"

GitLab CI

generate-sbom:
  stage: build
  image: anchore/syft:latest
  script:
    - syft dir:. -o cyclonedx-json > sbom.cdx.json
  artifacts:
    paths:
      - sbom.cdx.json
    expire_in: 90 days
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
    - if: $CI_COMMIT_TAG

Jenkins

pipeline {
    agent any

    stages {
        stage('SBOM erstellen') {
            steps {
                sh '''
                    curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b .
                    ./syft dir:. -o cyclonedx-json > sbom.cdx.json
                '''
            }
        }

        stage('SBOM archivieren') {
            steps {
                archiveArtifacts artifacts: 'sbom.cdx.json', fingerprint: true
            }
        }
    }
}

Docker Build Integration

SBOM während des Docker-Builds erstellen:

# Multi-Stage Build mit SBOM-Erstellung
FROM node:20 AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

# SBOM im Build-Stage erstellen
FROM anchore/syft:latest AS sbom
COPY --from=builder /app /app
RUN syft dir:/app -o cyclonedx-json > /sbom.cdx.json

# Finales Image
FROM node:20-slim
COPY --from=builder /app/dist /app
COPY --from=sbom /sbom.cdx.json /app/sbom.cdx.json
CMD ["node", "/app/index.js"]

SBOM-Signierung

Der CRA schreibt keine SBOM-Signierung vor. Eine Signatur belegt jedoch, dass die SBOM seit ihrer Erstellung nicht verändert wurde. Enterprise-Einkaufsteams und notifizierte Stellen erwarten zunehmend eine verifizierbare Signatur zusammen mit der SBOM-Datei.

Cosign (Teil des Sigstore-Projekts) ist das Standardtool:

# Cosign installieren
brew install cosign

# SBOM-Datei signieren. Erzeugt ein Bundle mit Signatur und Zertifikat
cosign sign-blob sbom.cdx.json --bundle sbom.cdx.json.sigstore.json

# Später verifizieren
cosign verify-blob sbom.cdx.json --bundle sbom.cdx.json.sigstore.json \
  --certificate-identity <your-identity> \
  --certificate-oidc-issuer <your-issuer>

Speichern Sie sbom.cdx.json und sbom.cdx.json.sigstore.json zusammen. Das Bundle enthält die Signatur, das Signierzertifikat und den Rekor-Transparenzlog-Eintrag. Jeder mit dem Bundle kann die SBOM verifizieren, ohne Sie zu kontaktieren.

Für CI/CD unterstützt Cosign Keyless-Signierung mit der OIDC-Identität der Pipeline (GitHub Actions, GitLab CI). Es gibt keine Schlüssel zu verwalten. Das GitHub-Actions-Beispiel oben enthält dies bereits: Der Job benötigt die Berechtigung id-token: write, und sign-blob verwendet --yes, um ohne interaktive Eingabe zu laufen. Ab Cosign 2.0 ist Keyless-Signierung der Standard; das alte COSIGN_EXPERIMENTAL-Flag wird nicht mehr benötigt.

Kontinuierliches Monitoring

Eine signierte, gespeicherte SBOM ist nicht das Ziel. Neue Schwachstellen werden für Komponenten gemeldet, die zum Zeitpunkt des Release sauber waren. Die gespeicherte SBOM muss regelmäßig erneut gescannt werden, damit diese CVEs sichtbar werden.

Grype liest eine vorhandene SBOM direkt, sodass der erneute Scan keine originale Build-Umgebung benötigt:

name: SBOM-Rescan

on:
  schedule:
    - cron: "0 6 * * 1"  # Wöchentlich, Montag 06:00 UTC

jobs:
  rescan:
    runs-on: ubuntu-latest
    steps:
      - name: Gespeicherte SBOM abrufen
        env:
          SBOM_URL: ${{ vars.SBOM_URL }}
        run: |
          curl -sSfL -o sbom.cdx.json "$SBOM_URL"

      - name: Grype installieren
        run: |
          curl -sSfL https://raw.githubusercontent.com/anchore/grype/main/install.sh | sh -s -- -b /usr/local/bin

      - name: SBOM auf neue CVEs scannen
        run: |
          grype sbom:./sbom.cdx.json

CRA Evidence führt diesen Rescan automatisch für jede hochgeladene SBOM durch und benachrichtigt Sie, wenn ein neuer CVE auf eine Komponente zutrifft.

SBOM-Qualität: TR-03183 erfüllen

Die deutsche BSI Technische Richtlinie TR-03183 erweitert die NTIA-Mindestanforderungen. EU-weit nicht rechtlich vorgeschrieben, gewährleistet die Befolgung von TR-03183 hochwertige SBOMs.

Erforderliche Felder

SBOM-Qualität validieren

Verwenden Sie diese Tools, um Ihre SBOM zu prüfen:

# CycloneDX-Format validieren
npm install -g @cyclonedx/cyclonedx-cli
cyclonedx validate --input-file sbom.cdx.json

# Auf Mindestfelder mit jq prüfen
jq '.components[] | select(.version == null or .purl == null)' sbom.cdx.json

# Komponenten mit Hashes zählen
jq '[.components[] | select(.hashes != null)] | length' sbom.cdx.json

SBOM-Qualität verbessern

Wenn Ihrer SBOM Daten fehlen:

1. Lock-Dateien verwenden: package-lock.json, Pipfile.lock, go.sum enthalten mehr Metadaten
2. Gebaute Artefakte scannen: Vollständiger als reine Quellcode-Scans
3. Tools kombinieren: Verschiedene Tools finden verschiedene Komponenten
4. Manuelle Einträge hinzufügen: Für kommerzielle oder interne Komponenten

SBOMs aktuell halten

Eine SBOM ist eine Momentaufnahme. Sie muss aktualisiert werden, um nützlich zu bleiben.

Wann neu generieren

• Bei jeder Veröffentlichung (Major, Minor, Patch)
• Nach Abhängigkeits-Updates
• Nach Sicherheitspatches
• Bei Änderungen der Build-Konfiguration

Versionierungsstrategie

produkt-v1.0.0-sbom.cdx.json
produkt-v1.0.1-sbom.cdx.json
produkt-v1.1.0-sbom.cdx.json

Oder mit Zeitstempeln:

produkt-sbom-2026-01-15T10-30-00Z.cdx.json

Aufbewahrung

Die CI-Artefakt-Aufbewahrung (90 Tage in den obigen Beispielen) dient dem Entwicklerkomfort, nicht der Compliance. Die 10-Jahres-Anforderung erfordert einen dedizierten Langzeitspeicher. CRA Evidence ist dafür konzipiert: versionierter SBOM-Speicher mit Schwachstellen-Rescanning und technischem Datei-Export, verknüpft mit jedem Produkt-Release.

Wenn Sie es selbst betreiben möchten, eignet sich jeder große Objektspeicher, sobald Sie die richtigen Steuerungsmechanismen aktivieren:

Eine Lifecycle-Richtlinie allein reicht nicht aus. Der Speicher muss auch Versionierung, Zugriffssteuerung und idealerweise Unveränderlichkeit unterstützen, um Prüfungsanforderungen zu erfüllen.

Häufige Fallstricke

Einmalige SBOM-Erstellung

Problem: Eine SBOM einmal erstellen und nie aktualisieren.

Lösung: Automatisieren Sie die SBOM-Erstellung in CI/CD. Jeder Build sollte eine frische SBOM produzieren.

Fehlende transitive Abhängigkeiten

Problem: SBOM listet nur direkte Abhängigkeiten auf, verschachtelte Pakete fehlen.

Lösung: Lock-Dateien verwenden, gebaute Artefakte scannen, Deep-Scanning-Optionen aktivieren.

Falsche Formatversion

Problem: CycloneDX 1.3 verwenden, obwohl TR-03183 1.4+ empfiehlt.

Lösung: Prüfen Sie die Ausgabeversion Ihres Tools. Aktualisieren Sie Tools regelmäßig.

Keine Hashwerte

Problem: Komponenten ohne kryptografische Hashes können nicht verifiziert werden.

Lösung: Stellen Sie sicher, dass Ihr Tool Hashes enthält. Syft und Trivy fügen SHA-256-Hashes hinzu, wenn sie die Komponentendateien lesen können.

Manuelle Erstellung

Problem: Handgefertigte SBOMs sind fehleranfällig und nicht nachhaltig.

Lösung: Immer automatisieren. Manuelle Einträge nur für Komponenten, die Tools nicht erkennen können.

Interne Komponenten ignorieren

Problem: Nur Open-Source-Abhängigkeiten dokumentieren, nicht proprietären Code.

Lösung: Interne Komponenten benötigen auch Dokumentation. Fügen Sie sie manuell hinzu oder konfigurieren Sie Tools entsprechend.

SBOM-Implementierungs-Checkliste

Anforderungen: Erfahren Sie, was der CRA für SBOMs verlangt, in unserem SBOM-Anforderungsleitfaden.

Qualität: Validieren Sie Ihre SBOM gegen den BSI TR-03183 Standard.

VEX: Fügen Sie Schwachstellen-Kontext zu Ihrer SBOM mit VEX-Dokumenten hinzu.

Dieser Artikel dient nur zu Informationszwecken und stellt keine Rechtsberatung dar. Für spezifische Compliance-Beratung konsultieren Sie qualifizierte Rechtsberater, die mit EU-Produktvorschriften vertraut sind.