Supply Chain Security — Du deployst Dependencies ohne SBOM. SolarWinds-Angriff, dein Build-System ist kompromittiert. Alle Container sind bösartig.
Du deployst Dependencies ohne SBOM. SolarWinds-Angriff, dein Build-System ist kompromittiert. Alle Container sind bösartig. Hier ist, wie du das verhinderst.
Was ist Supply Chain Security? Einfach erklärt.
Supply Chain Security bedeutet: deine Software-Lieferkette absichern — von Dependencies über Build-System bis Deployment. Risiken: kompromittierte Packages (SolarWinds, XZ Utils), Typosquatting, Dependency Confusion, malicious Maintainer. Gute Supply Chain Security: SBOM-Generierung, Dependency Pinning, Container Signing (Sigstore), Build Provenance, Dependency Scanning in CI/CD.
↓ Springe direkt zur technischen Tiefe4 Supply Chain Controls
Software Bill of Materials (SBOM) mit Syft generieren und mit Grype auf Vulnerabilities prüfen.
# SBOM mit Syft generieren (CycloneDX Format) syft packages dir:. -o cyclonedx-json > sbom.json # SBOM auf Vulnerabilities prüfen (Grype) grype sbom:sbom.json --fail-on critical # npm SBOM (für Node.js) npm sbom --sbom-format cyclonedx > npm-sbom.json # Container SBOM syft ghcr.io/clawguru/openclaw:latest \ -o cyclonedx-json > container-sbom.json
Dependencies auf spezifische Versionen pinnen — keine floating Tags (latest), SHA256-Digests für Container Images.
# package-lock.json committen (Node.js)
# Lock-File enthält exakte Versionen und Hashes
# Container Images mit SHA256-Digest pinnen
# BAD: myimage:latest
# GOOD: myimage@sha256:abc123...
# Docker Compose mit Digests
services:
app:
image: myimage@sha256:abc123def456...Container Images mit cosign signieren und verifizieren — Build Provenance und Integrity Checks.
# Container Image signieren cosign sign --key cosign.key ghcr.io/clawguru/openclaw:latest # Image verifizieren (Deployment) cosign verify ghcr.io/clawguru/openclaw:latest # SBOM Attestation anhängen cosign attest \ --predicate sbom.json \ --type cyclonedx \ ghcr.io/clawguru/openclaw:latest # Attestation verifizieren cosign verify-attestation \ --type cyclonedx \ ghcr.io/clawguru/openclaw:latest
Automatisches Dependency Scanning in CI/CD-Pipeline — npm audit, pip-audit, trivy als Pflichtschritt.
# GitHub Actions: npm audit
- name: Run npm audit
run: npm audit --audit-level=moderate
# Trivy FS Scan
- name: Run Trivy vulnerability scanner
uses: aquasecurity/trivy-action@master
with:
scan-type: 'fs'
scan-ref: '.'
format: 'sarif'
output: 'trivy-results.sarif'
# Bei HIGH/CRITICAL Build abbrechen
# Fail fast on security issuesReal-World Scars: Production Incidents
Build-System kompromittiert, malicious Code in Orion Updates verteilt. 18.000+ Kunden betroffen. Fix: Hermetic Builds, Build Provenance, Container Signing.
Malicious Maintainer platzierte Backdoor in XZ Utils (SSH-Server). SSH-Keys kompromittiert. Fix: Minimal Dependencies, Maintainer-Audit, SBOM-Verifikation.
Sofortmaßnahmen: Was heute tun?
SBOM generieren
Syft installieren, SBOM für alle Images generieren.
Dependency Pinning
package-lock.json committen, Container-Images mit SHA256 pinnen.
Sigstore einrichten
cosign installieren, Images signieren und verifizieren.
CI/CD Dependency Scanning
npm audit/trivy in CI-Pipeline als Pflichtschritt.
Interaktive Supply Chain Security Checkliste
Supply Chain Security Score Calculator
Industrie-Durchschnitt: 15/100
Häufige Fragen
Was ist ein SBOM und warum brauche ich es?
SBOM (Software Bill of Materials) ist eine inventarisierte Liste aller Dependencies in deiner Software — inklusive Versionen, Lizenzen und Vulnerabilities. Brauchst du für: Compliance (NIST, EU AI Act), Incident Response (welche Pakete sind betroffen?), Vulnerability Management (proaktives Scanning), Supply Chain Security (Transparenz über deine Dependencies).
Dependency Pinning vs Latest — was nutzen?
Immer pinnen. Floating Tags (latest, v2, main) sind ein Security-Risiko — du weißt nicht, was deployt wird. Pinning: package-lock.json (Node.js), requirements.txt mit Hashes (Python), SHA256-Digests für Container Images. Ausnahme: Dev-Dependencies können auto-update mit Renovate/Dependabot.
Sigstore vs GPG für Container Signing?
Sigstore (cosign) ist moderner und einfacher: Keine Key-Management-Overhead (Keys werden in Rekorde-Log gespeichert), OIDC-Integration für CI/CD (GitHub Actions, GitLab CI), Build Provenance automatisch attestiert, Verifikation ohne Key-Exchange. GPG: Manuelle Key-Management, Build Provenance manuell, komplexere Integration. Empfehlung: Sigstore für neue Projekte.
Schutz vor SolarWinds-artigen Angriffen?
SolarWinds war ein Supply-Chain-Angriff über kompromittierte Build-Systeme. Schutz: Hermetic Builds (Build in isolierter Umgebung ohne Internet), Build Provenance (Wer hat wann was gebaut?), SBOM-Verifikation (Stimmt die SBOM mit dem Deploy überein?), Container Signing (Nur signierte Images deployen), CI/CD-Hardening (MFA, Branch Protection, Audit Logs).