# Implementation Playbook — curated KNOWLEDGE (the "wie komme ich dort hin?" layer), not runtime code.
# Capability: sbom_creation. Expert FIRST DRAFT — an SBOM practitioner would validate this; it is
# NOT a normative requirement. The renderer (compliance/playbook) assembles it into the journey.

id: PB-sbom_creation-v1
capability_id: sbom_creation
status: draft                      # draft -> reviewed -> validated -> proven
version: 1

title: "Software Bill of Materials (SBOM) aufbauen und betreiben"

why: >
  Der CRA verlangt von Herstellern, die Komponenten ihres Produkts zu identifizieren und zu
  dokumentieren (Schwachstellenbehandlung, Annex I Teil II). Eine SBOM ist das maschinenlesbare
  Inventar aller (auch transitiven) Software-Bestandteile mit Version und Lizenz. Ohne SBOM kann
  niemand verlässlich sagen, welche Produkte von einer neuen Schwachstelle (CVE) betroffen sind —
  SBOM ist damit die Voraussetzung für Schwachstellenüberwachung, Security-Updates und Meldepflichten.

tools:
  - "CycloneDX (Format, OWASP)"
  - "SPDX (Format, Linux Foundation)"
  - "Syft (Generator, Container/Filesystem)"
  - "cdxgen (Generator, Multi-Ökosystem)"
  - "Trivy (Generator + Scan)"
  - "OWASP Dependency-Track (Verwaltung + kontinuierliche Überwachung)"

process_steps:
  - title: "Format festlegen"
    detail: "CycloneDX oder SPDX wählen (maschinenlesbar). CycloneDX ist im Security-Kontext verbreitet."
  - title: "Automatisch im Build erzeugen"
    detail: "SBOM-Generierung (Syft/cdxgen/Trivy) als Schritt in die CI/CD-Pipeline einbauen — pro Build, nicht manuell."
  - title: "Transitive Abhängigkeiten + Versionen + Lizenzen erfassen"
    detail: "Nicht nur direkte Dependencies; gerade transitive Komponenten tragen die meisten CVEs."
  - title: "Pro Release versionieren und ablegen"
    detail: "Jede ausgelieferte Produktversion bekommt ihre eigene, unveränderliche SBOM (Nachvollziehbarkeit)."
  - title: "An Schwachstellenüberwachung anbinden"
    detail: "SBOM in Dependency-Track laden -> kontinuierlicher Abgleich gegen neue CVEs/Advisories."
  - title: "Release-Gate setzen"
    detail: "Auslieferung nur mit gültiger SBOM (Reifegrad-Schritt) — verbindet SBOM mit dem Update-Prozess."

expected_evidence:
  - "Maschinenlesbare SBOM (CycloneDX/SPDX) je ausgelieferter Produktversion"
  - "CI-Job-Konfiguration, die die SBOM automatisch erzeugt"
  - "Dependency-Track-Projekt (oder gleichwertig) mit laufender Überwachung"

typical_controls:                  # INDIKATIV — echte Control-Zuordnung kommt aus der Execution-Schicht
  - "component_inventory"
  - "supply_chain_risk_management"

how_others_do_it: >
  Verbreitete Praxis: CycloneDX automatisch in der CI via Syft/cdxgen erzeugen und nach
  OWASP Dependency-Track pushen, das kontinuierlich gegen neue CVEs prüft. Reifere Organisationen
  gaten Releases auf das Vorhandensein einer SBOM und teilen sie auf Anfrage mit Kunden/Behörden.

disclaimer: >
  Kuratiertes Experten-Wissen (Erstentwurf), KEINE normative Anforderung. Werkzeug- und
  Schrittempfehlungen sind Beispiele bewährter Praxis, kein Pflichtkatalog. Review durch eine:n
  Product-Security-Expert:in ausstehend (status: draft).