CRA-konforme SBOM erstellen: Tools, Formate und CI/CD-Integration

Der CRA verlangt eine Software-Stückliste (SBOM). Jeder Wettbewerberartikel sagt Ihnen das. Keiner zeigt Ihnen, wie man eine erstellt.

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

Was der CRA tatsächlich erfordert

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

"Schwachstellen und im Produkt enthaltene Komponenten zu identifizieren und zu dokumentieren, unter anderem durch Erstellung einer Software-Stückliste in einem allgemein verwendeten und maschinenlesbaren Format"

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.

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 zu implementieren
• 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 Standard) 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.

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
    steps:
      - name: Code auschecken
        uses: actions/checkout@v4

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

      - name: SBOM erstellen
        run: |
          syft dir:. -o cyclonedx-json > sbom.cdx.json

      - name: SBOM als Artefakt hochladen
        uses: actions/upload-artifact@v4
        with:
          name: sbom
          path: sbom.cdx.json
          retention-days: 90

      # Optional: Zu CRA Evidence hochladen
      - name: Zu CRA Evidence hochladen
        if: github.event_name == 'release'
        env:
          CRA_EVIDENCE_TOKEN: ${{ secrets.CRA_EVIDENCE_TOKEN }}
        run: |
          curl -X POST https://app.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-Qualität: TR-03183 erfüllen

Die deutsche BSI Technische Richtlinie TR-03183 erweitert die NTIA-Mindestanforderungen. Obwohl 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

Der CRA erfordert 10-jährige Aufbewahrung. Speichern Sie historische SBOMs:

• In Ihrem Artefakt-Repository
• In S3/Cloud-Speicher mit Lifecycle-Richtlinien
• In CRA Evidence für integriertes Compliance-Tracking

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. Scannen Sie gebaute Artefakte anstatt nur Quellcode.

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

SBOM-IMPLEMENTIERUNGS-CHECKLISTE

FORMATAUSWAHL:
[ ] CycloneDX 1.4+ oder SPDX 2.3+ gewählt
[ ] JSON-Format (maschinenlesbar)
[ ] Entscheidung dokumentiert

TOOLING:
[ ] Primäres Tool ausgewählt (Syft/Trivy/cdxgen)
[ ] Tool installiert und lokal getestet
[ ] Ausgabe gegen Schema validiert

CI/CD-INTEGRATION:
[ ] SBOM-Erstellung zur Build-Pipeline hinzugefügt
[ ] Artefakte mit entsprechender Aufbewahrungsfrist gespeichert
[ ] Erstellung bei Releases ausgelöst

QUALITÄTSSICHERUNG:
[ ] Alle Komponenten haben: Name, Version, Lieferant
[ ] Hashwerte vorhanden (SHA-256+)
[ ] Lizenzinformationen enthalten
[ ] Transitive Abhängigkeiten erfasst
[ ] PURL-Identifikatoren verwendet

BETRIEB:
[ ] SBOM parallel zu Produktversionen versioniert
[ ] Historische SBOMs archiviert (10-jährige Aufbewahrung)
[ ] Prozess für Team dokumentiert

OPTIONAL - CRA EVIDENCE INTEGRATION:
[ ] API-Token konfiguriert
[ ] Upload bei Release automatisiert
[ ] Qualitätsbewertung aktiviert

Nächste Schritte

Mit automatisierter SBOM-Erstellung sind Sie bereit für:

1. Schwachstellen-Scanning: SBOMs mit Schwachstellendatenbanken verbinden
2. Lizenz-Compliance: Lizenzpflichten analysieren
3. Technische Dokumentation Integration: SBOMs in CRA-Dokumentation einbinden
4. ENISA-Meldevorbereitung: SBOMs ermöglichen schnelle Schwachstellen-Identifikation

CRA Evidence automatisiert diesen gesamten Workflow:

• SBOMs über CLI oder CI/CD hochladen
• Automatisches Schwachstellen-Scanning mit Trivy
• TR-03183 Qualitätsbewertung
• Technische Dokumentation Export mit integrierten SBOMs

Beginnen Sie mit der Erstellung konformer SBOMs unter app.craevidence.com.

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.