Benjamin Admin
78f0ffa9de
Roadmap item 4. After WHAT applies / WHAT is missing / WHICH first, the GF asks HOW. The Implementation Playbook renders, for one capability, the full journey — why / which regulations it closes / tools / process / evidence / controls — and chains the Optimization Roadmap into per-measure playbooks. Another renderer over the same Capability spine (ADR-003/004), not a new engine: ~95% of the data already exists, it just needs a different rendering. - compliance/playbook/: build_playbook() + playbooks_for_plan() (chains optimization -> playbook, acyclic; reuses leverage for "closes which regulations"). Capabilities without curated content render as honest status:missing stubs — the content-owed signal. - knowledge/implementation_playbooks/: curated knowledge layer (Reasoning Knowledge Acquisition), two deep expert drafts (SBOM, CVD/PSIRT, status draft, expert-draft-not-normative) + README. The bottleneck is now CONTENT, not software; Playbook (own knowledge) != regulatory domain. - ADR-004: Implementation Playbooks = renderer + knowledge layer; content is the bottleneck. - reference suite: "Implementation Playbook" section renders the SBOM journey + Roadmap->Playbook table (high-leverage caps flagged "fehlt (Inhalt)" — content backlog, highest leverage first). - refactor: extracted markdown helpers to reference_scenarios/_helpers.py to keep generate.py under the 500-LOC budget. 9 playbook tests (40 with optimization+transition+company), mypy --strict clean, check-loc 0. Product code with no app caller + knowledge/ADR/reference = non-runtime -> no deploy (ADR-001). Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
59 lines
3.1 KiB
YAML
59 lines
3.1 KiB
YAML
# 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).
|