SBOM - Software Bill of Materials - Definition & Erklärung

SBOM (Software Bill of Materials) beantwortet eine Frage die während Log4Shell (Dezember 2021) millionen IT-Teams gleichzeitig stellten: “Nutzen wir log4j? Wenn ja, wo?” Ohne SBOM: wochenlange manuelle Suche durch hunderte Repositories. Mit SBOM: Antwort in Sekunden.

SBOM-Formate

SPDX (Software Package Data Exchange)

Entwickelt von Linux Foundation
ISO/IEC 5962:2021 (internationaler Standard)
Formate: .spdx (Tag-Value), .json, .yaml, .xml, .rdf
Stärke: beste Lizenz-Compliance-Unterstützung
Tooling: syft, spdx-tools, fossology

{
  "spdxVersion": "SPDX-2.3",
  "name": "myapp",
  "packages": [{
    "SPDXID": "SPDXRef-log4j",
    "name": "log4j-core",
    "version": "2.14.1",
    "supplier": "Organization: Apache Software Foundation",
    "licenseDeclared": "Apache-2.0",
    "externalRefs": [{
      "referenceCategory": "SECURITY",
      "referenceType": "cpe23Type",
      "referenceLocator": "cpe:2.3:a:apache:log4j:2.14.1:*"
    }]
  }]
}

CycloneDX

Entwickelt von OWASP
Fokus: Security-Use-Cases (Vulnerability Management)
Formate: .json, .xml
Stärke: beste Security-Tool-Integration
Tooling: cdxgen, syft, Dependabot
VEX (Vulnerability Exploitability eXchange) als Erweiterung

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "components": [{
    "type": "library",
    "name": "log4j-core",
    "version": "2.14.1",
    "group": "org.apache.logging.log4j",
    "purl": "pkg:maven/org.apache.logging.log4j/log4j-core@2.14.1",
    "licenses": [{"license": {"id": "Apache-2.0"}}],
    "vulnerabilities": [{
      "id": "CVE-2021-44228",
      "ratings": [{"severity": "critical", "score": 10.0}]
    }]
  }]
}

SWID (Software Identification Tags)

ISO/IEC 19770-2 Standard
Fokus: Asset Management, Software-Inventarisierung
Weniger verbreitet in Open-Source-Tooling
Häufiger bei kommerzieller Software (Windows-Installer)

Empfehlung nach Anwendungsfall

Anwendungsfall	Empfohlenes Format
Security-Fokus	CycloneDX (beste CVE-Integration)
Lizenz-Compliance	SPDX
Enterprise/Asset	SWID + SPDX

SBOM generieren

# syft (Anchore - Open Source)
# Installation:
curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh

# Python-Projekt:
syft dir:./myapp -o spdx-json=sbom.spdx.json
syft dir:./myapp -o cyclonedx-json=sbom.cdx.json

# Docker-Image:
syft nginx:latest -o spdx-json=nginx-sbom.spdx.json

# NPM-Projekt:
syft dir:./webapp --catalogers javascript-lock-file

# cdxgen (CycloneDX Generator - OWASP)
npm install -g @cyclonedx/cdxgen
cdxgen -t nodejs -o bom.json ./myapp
cdxgen -t python -o bom.json ./myapp
cdxgen -t java -o bom.json ./myapp
# Unterstützt 30+ Sprachen/Ökosysteme

# Trivy (Aqua Security)
# SBOM aus Image:
trivy image --format cyclonedx --output sbom.json nginx:latest
# SBOM aus Dateisystem:
trivy fs --format spdx-json --output sbom.json ./

# GitHub Dependency Graph (SaaS)
# Automatisch für alle GitHub Repos (wenn aktiviert)
# Export via API:
gh api /repos/{owner}/{repo}/dependency-graph/sbom > sbom.json

# SBOM-Signierung (für Vertrauenskette) via Sigstore cosign:
cosign attach sbom --sbom sbom.cdx.json container-image:tag
cosign verify-blob sbom.cdx.json --certificate cert.pem
# SBOM-Signierung wichtig für:
# → Lieferketten-Vertrauen (ich beweise: dieses SBOM ist von mir)
# → Unveränderlichkeit (SBOM wurde nicht manipuliert)

SBOM für Vulnerability Management

# grype - Vulnerability Scanner mit SBOM-Input (Anchore)

# grype installieren:
curl -sSfL https://raw.githubusercontent.com/anchore/grype/main/install.sh | sh

# Direkt auf Image scannen:
grype nginx:latest

# Auf SBOM-Datei scannen (schneller, offline möglich!):
grype sbom:./sbom.spdx.json

Ausgabe:

NAME         INSTALLED  FIXED-IN  VULNERABILITY   SEVERITY
log4j-core   2.14.1     2.17.1    CVE-2021-44228  Critical
log4j-api    2.14.1     2.17.1    CVE-2021-44228  Critical

# Exit-Code für CI/CD:
grype sbom:./sbom.json --fail-on critical
# exit 1 wenn Critical CVEs gefunden → Build schlägt fehl!

Log4Shell-Beispiel: SBOM vs. kein SBOM

Szenario: 10. Dezember 2021, CVE-2021-44228 publiziert.

Ohne SBOM:

IT: “Haben wir log4j irgendwo?”
Dev Team A: “Glaube nicht, check mal…”
Dev Team B: “Wir bauen auf Spring, keine Ahnung ob das dabei ist”
3 Wochen manuelles Suchen in hunderten Repos…

Mit SBOM:

grype sbom:service-a/sbom.json --fail-on critical  # → 0 findings
grype sbom:service-b/sbom.json --fail-on critical  # → FAIL: log4j 2.14.1!
grype sbom:service-c/sbom.json --fail-on critical  # → 0 findings
grype sbom:service-d/sbom.json --fail-on critical  # → FAIL: log4j 2.12.3!

10 Minuten um alle betroffenen Services zu identifizieren → sofortiger Patch-Plan für genau 2 von 10 Services.

VEX (Vulnerability Exploitability eXchange)

Ergänzt SBOM: “CVE-XYZ ist zwar vorhanden, aber nicht ausnutzbar weil…” Reduziert False Positives (z.B. CVE in Code-Pfad der nie ausgeführt wird).

{
  "vulnerabilities": [{
    "id": "CVE-2021-44228",
    "analysis": {
      "state": "not_affected",
      "justification": "code_not_reachable",
      "response": ["will_not_fix"],
      "detail": "log4j-core is bundled but JndiLookup class is disabled in deployment"
    }
  }]
}

Regulatorische SBOM-Anforderungen

US Executive Order 14028 (Mai 2021)

“Improving the Nation’s Cybersecurity”
SBOM-Pflicht für Softwareanbieter der US-Bundesbehörden
Baseline-Definition: NTIA-Minimum-Elements für SBOM
Wirkung: US-Markt → indirekt globale Anforderung

EU Cyber Resilience Act (CRA) - gültig ab 2027

Gilt für alle “Products with Digital Elements” im EU-Markt
Anforderung: “Vulnerability Disclosure Policy” + SBOM-ähnliche Dokumentation
Annex I: technische Dokumentation inkl. aller Abhängigkeiten
Geldbußen: bis 15M EUR oder 2,5% des Jahresumsatzes
Betrifft: fast jede Software die in der EU verkauft wird

NIS2-Richtlinie (seit Oktober 2024)

Art. 21: “Sicherheit der Lieferkette” als Pflichtkontrolle
SBOM als Umsetzungsmittel für Supply-Chain-Security
Kritische Einrichtungen: detailliertere Anforderungen

NTIA Minimum Elements (US, Oktober 2021)

6 Pflichtfelder pro Komponente:

Supplier Name (Hersteller)
Component Name
Component Version
Other Unique Identifiers (PURL, CPE)
Dependency Relationship (wer hängt von wem ab?)
Author of SBOM Data

Best Practices für SBOM-Implementierung

SBOM in CI/CD generieren (jeder Build → neues SBOM)
SBOMs signieren (Sigstore cosign)
SBOMs in Artifact Registry speichern (neben Docker-Image)
Automatisierter Schwachstellenscan gegen SBOM (grype in Pipeline)
SBOM-Retention: mindestens so lange wie Software supported wird
Transitive Dependencies einschließen (A → B → C: alle drei!)