SBOM – Software Bill of Materials

Von Boris Sander•11. November 2025
SBOM – Software Bill of Materials

SBOM – Software Bill of Materials

„Was ist eigentlich in dieser Software drin?" – Die Frage, die nach Log4Shell jeder stellen musste.

Sinn & Zweck

Ein SBOM ist das Zutatenliste deiner Software. Genau wie ein Lebensmittelhersteller auflisten muss, was in seinen Produkten steckt, listet ein SBOM alle Komponenten einer Software auf:

  • Welche Libraries werden genutzt?
  • In welchen Versionen?
  • Unter welchen Lizenzen?
  • Mit welchen bekannten Vulnerabilities?

Nach Log4Shell im Dezember 2021 wurde schmerzhaft klar: Die meisten Unternehmen wissen nicht, wo überall Log4j steckt. Ein SBOM hätte die Antwort in Minuten statt Wochen geliefert.

Warum SBOM jetzt wichtig ist

Regulatorischer Druck

USA:

  • Executive Order 14028 (Mai 2021): SBOM-Pflicht für Software, die an US-Behörden verkauft wird
  • CISA/NTIA Guidelines

EU:

  • Cyber Resilience Act: SBOM-Anforderungen für CE-Kennzeichnung
  • NIS2-Richtlinie: Supply-Chain-Security

Industrie:

  • Automotive: ISO/SAE 21434
  • Medical Devices: FDA Guidance
  • Finance: Zunehmende Anforderungen

Business-Treiber

Kunde: "Sind Sie von Log4Shell betroffen?"

Ohne SBOM:
Developer: "Äh... ich muss nachschauen... 
            dauert ein paar Tage... oder Wochen..."

Mit SBOM:
Developer: *query* "Nein, wir nutzen Log4j nicht." (5 Sekunden)

SBOM-Formate

CycloneDX

OWASP-Standard. Fokus auf Security.

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "serialNumber": "urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79",
  "version": 1,
  "metadata": {
    "timestamp": "2024-01-15T10:00:00Z",
    "tools": [{ "name": "syft", "version": "0.100.0" }],
    "component": {
      "type": "application",
      "name": "my-app",
      "version": "1.0.0"
    }
  },
  "components": [
    {
      "type": "library",
      "name": "lodash",
      "version": "4.17.21",
      "purl": "pkg:npm/lodash@4.17.21",
      "licenses": [{ "license": { "id": "MIT" } }],
      "hashes": [
        { "alg": "SHA-256", "content": "abc123..." }
      ]
    }
  ],
  "vulnerabilities": [
    {
      "id": "CVE-2021-23337",
      "source": { "name": "NVD" },
      "ratings": [{ "score": 7.2, "severity": "high" }],
      "affects": [
        { "ref": "pkg:npm/lodash@4.17.21" }
      ]
    }
  ]
}

SPDX

Linux Foundation Standard. Fokus auf Lizenzen.

{
  "spdxVersion": "SPDX-2.3",
  "dataLicense": "CC0-1.0",
  "SPDXID": "SPDXRef-DOCUMENT",
  "name": "my-app-sbom",
  "documentNamespace": "https://example.com/my-app-1.0.0",
  "creationInfo": {
    "created": "2024-01-15T10:00:00Z",
    "creators": ["Tool: syft-0.100.0"]
  },
  "packages": [
    {
      "SPDXID": "SPDXRef-Package-npm-lodash",
      "name": "lodash",
      "versionInfo": "4.17.21",
      "downloadLocation": "https://registry.npmjs.org/lodash/-/lodash-4.17.21.tgz",
      "licenseConcluded": "MIT",
      "externalRefs": [
        {
          "referenceCategory": "PACKAGE-MANAGER",
          "referenceType": "purl",
          "referenceLocator": "pkg:npm/lodash@4.17.21"
        }
      ]
    }
  ],
  "relationships": [
    {
      "spdxElementId": "SPDXRef-DOCUMENT",
      "relatedSpdxElement": "SPDXRef-Package-npm-lodash",
      "relationshipType": "DESCRIBES"
    }
  ]
}

SWID Tags

ISO/IEC 19770-2. Älterer Standard, weniger verbreitet.

Format-Vergleich

AspektCycloneDXSPDXSWID
FokusSecurityLizenzAsset Management
VulnerabilitiesNativeVia ExtensionNein
AdoptionSteigendEtabliertGering
ToolingGutGutBegrenzt
JSON/XMLBeideBeideXML

SBOM-Generierung

Tools

ToolTypUnterstütztBesonderheit
SyftCLI/LibraryContainer, FilesystemsSehr umfassend
TrivyScannerContainer, IaC, SBOMVuln-Scanning integriert
CycloneDX ToolsEcosystemSprach-spezifischOfficial CycloneDX
SPDX ToolsEcosystemSprach-spezifischOfficial SPDX
SnykCommercialAllesIntegration mit Fix-Vorschlägen
FOSSACommercialFokus ComplianceLicense-Management

Syft (Anchore)

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

# SBOM für Container-Image
syft alpine:latest -o cyclonedx-json > sbom.json

# SBOM für Verzeichnis
syft dir:./my-project -o spdx-json > sbom.json

# SBOM für spezifisches Manifest
syft file:./package-lock.json -o cyclonedx-json

# Verschiedene Formate
syft alpine:latest -o spdx-tag-value    # SPDX Tag-Value
syft alpine:latest -o spdx-json         # SPDX JSON
syft alpine:latest -o cyclonedx-json    # CycloneDX JSON
syft alpine:latest -o cyclonedx-xml     # CycloneDX XML
syft alpine:latest -o json              # Syft JSON
syft alpine:latest -o table             # Human-readable

Sprach-spezifische Tools

Node.js:

# CycloneDX
npx @cyclonedx/cyclonedx-npm --output-file sbom.json

# Mit npm audit info
npm sbom --sbom-format cyclonedx

Python:

# CycloneDX
cyclonedx-py -r requirements.txt -o sbom.json

# Mit Poetry
cyclonedx-py poetry -o sbom.json

Java/Maven:

<!-- pom.xml -->
<plugin>
    <groupId>org.cyclonedx</groupId>
    <artifactId>cyclonedx-maven-plugin</artifactId>
    <version>2.7.9</version>
    <executions>
        <execution>
            <goals>
                <goal>makeBom</goal>
            </goals>
        </execution>
    </executions>
</plugin>

mvn cyclonedx:makeBom

Go:

# CycloneDX
cyclonedx-gomod mod -json > sbom.json

# Mit Syft
syft dir:. -o cyclonedx-json

SBOM in CI/CD

GitHub Actions

name: Generate SBOM
on: [push]

jobs:
  sbom:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      
      - name: Generate SBOM
        uses: anchore/sbom-action@v0
        with:
          path: .
          format: cyclonedx-json
          output-file: sbom.json
      
      - name: Upload SBOM
        uses: actions/upload-artifact@v3
        with:
          name: sbom
          path: sbom.json
      
      - name: Scan for vulnerabilities
        uses: anchore/scan-action@v3
        with:
          sbom: sbom.json
          fail-build: true
          severity-cutoff: high

GitLab CI

generate-sbom:
  image: anchore/syft:latest
  script:
    - syft dir:. -o cyclonedx-json > sbom.json
  artifacts:
    paths:
      - sbom.json
    reports:
      cyclonedx: sbom.json  # Native GitLab Integration

Container Build

# Multi-stage mit SBOM
FROM node:18 AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci

FROM node:18-slim
COPY --from=builder /app/node_modules /app/node_modules
COPY . /app
WORKDIR /app

# SBOM als Label (Docker BuildKit)
# docker build --sbom=true -t myapp .

SBOM-Analyse & Nutzung

Vulnerability Scanning

# Grype (Anchore) mit SBOM
grype sbom:./sbom.json

# Trivy mit SBOM
trivy sbom sbom.json

# Output:
# NAME      INSTALLED  VULNERABILITY  SEVERITY
# lodash    4.17.20    CVE-2021-23337 HIGH
# minimist  1.2.5      CVE-2021-44906 CRITICAL

License Compliance

# Lizenz-Report aus SBOM
# Finde alle GPL-Komponenten
jq '.components_old[] | select(.licenses[].license.id | test("GPL"))' sbom.json

# Lizenz-Übersicht
jq '.components_old[].licenses[].license.id' sbom.json | sort | uniq -c

Dependency Graph

my-app@1.0.0
├── express@4.18.2
│   ├── accepts@1.3.8
│   │   ├── mime-types@2.1.35
│   │   └── negotiator@0.6.3
│   ├── body-parser@1.20.1
│   │   ├── bytes@3.1.2
│   │   └── content-type@1.0.5
│   └── ...
└── lodash@4.17.21 (VULNERABLE!)

SBOM-Datenbank

# SBOM in Datenbank speichern für Suche
# "Welche Produkte nutzen Log4j 2.14.1?"

# Schema (vereinfacht)
CREATE TABLE products (
    id UUID PRIMARY KEY,
    name VARCHAR,
    version VARCHAR,
    sbom_generated_at TIMESTAMP
);

CREATE TABLE components (
    id UUID PRIMARY KEY,
    product_id UUID REFERENCES products(id),
    name VARCHAR,
    version VARCHAR,
    purl VARCHAR,
    license VARCHAR
);

-- Query: Alle Produkte mit Log4j
SELECT p.name, p.version, c.version 
FROM products p
JOIN components c ON p.id = c.product_id
WHERE c.name LIKE '%log4j%' AND c.version < '2.17.0';

SBOM-Sharing

Wo speichern?

OptionBeschreibungZugriff
Im ProduktAls Datei mitgeliefertEinfach
RegistryOCI Registry, npm, etc.Automatisiert
SBOM RepositoryZentrale DatenbankEnterprise
Dependency-TrackOWASP ToolUmfassend

OCI Registry

# SBOM als OCI Artifact
oras push myregistry.com/myapp:v1.0.0-sbom \
    --artifact-type application/vnd.cyclonedx+json \
    sbom.json:application/vnd.cyclonedx+json

Dependency-Track (OWASP)

# SBOM hochladen
curl -X POST https://dependency-track.example.com/api/v1/bom \
    -H "Content-Type: application/vnd.cyclonedx+json" \
    -H "X-Api-Key: $API_KEY" \
    -d @sbom.json

Risiken & Grenzen

Unvollständigkeit

SBOM zeigt: lodash@4.17.21
Reality: Build-Prozess patcht lodash mit Custom-Fixes

SBOM zeigt: 47 Dependencies
Reality: 3 davon werden gar nicht genutzt (dead code)

Aktualität

Ein SBOM ist ein Snapshot. Morgen können neue CVEs entdeckt werden.

Qualität variiert

Gutes SBOM:
- Vollständige Dependency-Tree
- Korrekte Versionen
- Hashes für Integrität
- Lizenz-Informationen

Schlechtes SBOM:
- Nur Top-Level Dependencies
- Keine Versionen
- Keine Hashes
- "License: Unknown"

Tooling-Inkonsistenz

Verschiedene Tools generieren unterschiedliche SBOMs für dasselbe Projekt.

False Sense of Security

"Wir haben ein SBOM!" bedeutet nicht automatisch Sicherheit.

Vorteile

Transparenz

Du weißt endlich, was in deiner Software steckt. Alle 1.247 Dependencies.

Schnelle Incident Response

Breaking News: Kritische Vulnerability in XYZ Library!

Mit SBOM:
$ grep -l "XYZ" */sbom.json
product-a/sbom.json
product-c/sbom.json
# 2 Produkte betroffen, Rest ist safe
# Zeit: 30 Sekunden

Compliance

  • Open-Source-Lizenz-Compliance
  • Export-Kontrollen
  • Regulatorische Anforderungen

Supply Chain Visibility

Verstehe deine Abhängigkeiten:

  • Wer maintained sie?
  • Wie alt sind sie?
  • Welche Risiken bestehen?

Kunden-Vertrauen

Kunden fragen zunehmend nach SBOMs als Teil der Due Diligence.

Best Practices

1. Automatische Generierung

# Bei jedem Release automatisch SBOM erstellen
on:
  release:
    types: [published]
jobs:
  sbom:
    steps:
      - uses: anchore/sbom-action@v0

2. Signieren

# SBOM mit Cosign signieren
cosign sign-blob --key cosign.key sbom.json > sbom.json.sig

3. Versionieren

sbom-myapp-v1.0.0-20240115.json
sbom-myapp-v1.0.1-20240120.json

4. Zentral speichern

Alle SBOMs an einem Ort für schnelle Suche.

5. Kontinuierlich scannen

SBOMs regelmäßig gegen aktuelle CVE-Datenbanken prüfen.

6. Mit Kunden teilen

SBOM als Teil der Dokumentation oder auf Anfrage.

SBOM Maturity Model

LevelBeschreibung
0Keine SBOMs
1Manuelle SBOM-Erstellung bei Bedarf
2Automatische SBOM-Generierung in CI/CD
3Zentrales SBOM-Repository mit Vuln-Scanning
4Kontinuierliches Monitoring, automatische Alerts
5SBOM-Integration in Procurement, Customer-Facing

Fazit

SBOM ist die Antwort auf die Frage: "Was ist in meiner Software?" Nach Log4Shell ist klar, dass diese Antwort in Minuten verfügbar sein muss, nicht in Wochen.

Die Regulierung kommt. Die Tools sind da. Die Frage ist nur: Bist du bereit?

Eine Software ohne SBOM ist wie ein Lebensmittel ohne Zutatenliste: Du weißt nicht, was drin ist, bis du allergisch reagierst.

Weiterführende Ressourcen: