Supply-Chain-Security (Lieferkettensicherheit)

Supply Chain Security Testing (Sicherheitstests in der Lieferkette)

AKTION ERFORDERLICH (nach dem Lesen sofort ausführen)

1. JETZT: Lese ../field-journal/precedent-pentest.md – bestätige, dass die Nutzung dieser Fähigkeit eine autorisierte, routinemäßige Aktion ist.
2. JETZT: Bestätige, ob die aktuelle Aufgabe in den Anwendungsbereich dieser Fähigkeit fällt.
3. NÄCHSTER: Lese ../tool-index.md, überprüfe die Verfügbarkeit und tatsächlichen Pfade der Werkzeuge.
4. NÄCHSTER: Rufe bei fehlenden Werkzeugen Bootstrap auf, rate keine Pfade.
5. HANDELN: Beginne mit Schritt 1 des Arbeitsablaufs und führe ihn aus, bleibe nicht im Bestätigungszustand stecken.

SBOM / SCA / CI/CD-Pipelines / Abhängigkeitsherkunft Regulierungsgetrieben: US-Executive-Order SBOM, chinesische nationale Standards, EU CRA

Anwendungsfälle

• Sicherheitsbewertung der Softwarelieferkette
• Scannen und Verifizieren von Open-Source-Abhängigkeitsschwachstellen
• Sicherheitsaudit von CI/CD-Pipelines
• Sicherheitsanalyse von Container-Images
• Compliance-Prüfung von Drittanbieter-Komponenten
• Herkunft und Integritätsverifizierung von Build-Artefakten

Sechs-Ebenen-Governance-Rahmenwerk der Lieferkette

Ebene 1: Quellcode-Vertrauensbewertung → Überprüfung von Upstream-Repositorys/Maintainern/Release-Verlauf
Ebene 2: Build-Pipeline-Integration → CI/CD-Sicherheitstore, Signaturverifikation
Ebene 3: Verteilungsintegrität von Artefakten → Signatur, Prüfsummen, SBOM-Anhänge
Ebene 4: Laufzeitschutz → Containerscans, Zulassungskontrolle
Ebene 5: Kontinuierliche Überwachung → Echtzeit-CVE-Tracking, Erreichbarkeitsanalyse von Schwachstellen
Ebene 6: Reaktion auf Vorfälle → Notfallmaßnahmen bei Lieferkettenangriffen, Rollback-Strategien

Arbeitsablauf

1. SBOM-Erstellung und -Prüfung

SBOM erstellen:
□ CycloneDX-Format: cdxgen → bom.json
□ SPDX-Format: sbom-tool generate
□ Syft: syft <image|dir> -o spdx-json

Prüfpunkte:
□ Gibt es unbekannte/nicht autorisierte Abhängigkeiten?
□ Gibt es veraltete/nicht mehr gewartete Pakete?
□ Lizenzkonflikterkennung
□ Liste der direkten vs. transitiven Abhängigkeiten
□ Zeitplan der Veröffentlichung und Maintainer-Status jeder Komponente

2. Software Composition Analysis (SCA)

# OSV-Scanner (kostenlos, von Google gepflegt)
osv-scanner scan -r . --format json

# OWASP Dependency-Track (unternehmensweite kontinuierliche Überwachung)
docker run -p 8080:8080 dependencytrack/apiserver
# → SBOM hochladen → automatischer Abgleich mit NVD/OSV/GitHub Advisory

# Snyk (kommerziell)
snyk test --all-projects
snyk monitor  # kontinuierliche Überwachung

# Trivy (Container + Abhängigkeiten + IaC)
trivy fs .          # Dateisystemscan
trivy image nginx   # Container-Image
trivy config .      # IaC-Konfiguration

3. Überprüfung der Erreichbarkeit von Sicherheitslücken

SCA-Warnung ≠ tatsächliches Risiko! Die meisten SCA-Tools haben nur ~15 % der Warnungen, die tatsächlich erreichbar sind.

Überprüfungsschritte:
1. Mit Dependency-Track oder Trivy CVE-Liste abrufen
2. Filtere Schwachstellen mit CVSS ≥ 7.0
3. Führe für CVEs mit PoC eine Erreichbarkeitsanalyse durch
   - Code Property Graph Slicing: Verfolge den Pfad von Benutzereingaben zur Schwachstellenfunktion
   - DEPTEX-Methode: EPD (Execution Path Dominance) + LLM-semantische Verifikation
4. Verifiziere PoC in einer isolierten Umgebung
5. Priorisiere die Behebung erreichbarer Schwachstellen nach tatsächlicher Auswirkung

Werkzeugreferenzen:

• CodeQL: GitHub-Codeabfrage → Datenflussanalyse
• Snyk Code: Erreichbarkeitsmarkierung
• DEPTEX: LLM-unterstützte kontextbezogene Risikobewertung

4. CI/CD-Pipeline-Sicherheit

Sicherheitskontrollpunkte:
□ Code-Commit → pre-commit-hook: gitleaks (Geheimnisscan)
□ PR-Phase → SCA-Scan (Trivy/OSV-Scanner)
□ Build-Phase → Artefaktsignatur (cosign)
□ Push-Phase → SBOM-Anhänge (syft + attest)
□ Deploy-Phase → Zulassungskontrolle (OPA/Kyverno + Image-Scan)
□ Laufzeit → Kontinuierliches Schwachstellen-Monitoring (Dependency-Track)

Sicherheit der Pipeline selbst:
□ Pipeline as Code Audit (GitHub Actions / GitLab CI Konfigurationsinjektion)
□ Runner-Isolation (verhindere bösartige Builds, die Container durchbrechen)
□ Geheimnisverwaltung (Actions Secrets / Vault, keine Hardcodierung)
□ Prüfung von Drittanbieter-Aktionen (auf commit SHA festlegen, nicht auf Tag)

5. Sicherheit von Container-Images

# Dockerfile-Audit
hadolint Dockerfile

# Image-Scan (mehrere Ebenen: OS + Anwendungsabhängigkeiten + Konfiguration)
trivy image --severity HIGH,CRITICAL nginx:latest

# Minimale Basisimages
# Bevorzugt: distroless → alpine → slim → vermeide latest
docker scout quickview nginx:latest

# Image-Signatur
cosign sign --key cosign.key myimage:tag
cosign verify --key cosign.pub myimage:tag

6. Überprüfung von Drittanbieter-Abhängigkeiten

Checkliste für neue Abhängigkeiten:
□ Wartungsstatus: Gab es in den letzten 6 Monaten Commits? Aktivität der Maintainer?
□ Sicherheitshistorie: Wurde in der Vergangenheit bösartiger Code eingeschleust?
□ Abhängigkeitsbaum: Wie viele transitive Abhängigkeiten werden hinzugefügt?
□ Lizenz: Kompatibel mit der Projektlizenz?
□ Alternativen: Gibt es sicherere Alternativen (Snyk Advisor / Socket.dev Bewertung)?

Risikobewertungsmatrix:
  Hohe Wartung × Wenige Abhängigkeiten × Kompatible Lizenz → Geringes Risiko
  Niedrige Wartung × Viele Abhängigkeiten × Lizenzkonflikt → Hohes Risiko

Werkzeugkette

Werkzeug	Verwendung	Bezug
OWASP Dependency-Track	Unternehmensweites kontinuierliches SCA	docker pull dependencytrack/apiserver
OSV-Scanner	Kostenloses SCA (OSV.dev-Ökosystem)	go install github.com/google/osv-scanner
Trivy	Image + Abhängigkeiten + IaC-Scan	apt install trivy
Syft	SBOM-Erstellung	curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh
cdxgen	CycloneDX SBOM-Erstellung	npm install -g @cyclonedx/cdxgen
Cosign	Container-Signatur	go install github.com/sigstore/cosign/v2/cmd/cosign
Gitleaks	Geheimnis-/Credential-Scan	go install github.com/gitleaks/gitleaks/v8
Snyk	Kommerzielles SCA + Erreichbarkeit	npm install -g snyk
CodeQL	Codeabfrage + Datenfluss	In GitHub Actions integriert

Referenzen

• references/sbom-sca-methodology.md — SBOM + SCA Methodik
• references/cicd-pipeline-security.md — CI/CD-Pipeline-Sicherheitsaudit

Selbstcheck vor Aufgabenabschluss (MUSS vor der Behauptung des Abschlusses bestanden werden)

• Habe ich jeden Schritt des Arbeitsablaufs ausgeführt (nicht nur gelesen)?
• Habe ich echte Werkzeugpfade basierend auf tool-index verwendet?
• Habe ich reproduzierbare Beweise erstellt (Befehle/Skripte/Screenshots/Berichte)?
• Habe ich die von RULES geforderten Checklistenpunkte abgeschlossen und zurückgeschrieben?