Software-Lieferketten: Das stille Einfallstor

Management Summary

Angriffe über Abhängigkeiten sind kein Randthema mehr, sondern die bequeme Abkürzung ins Herz moderner IT. Die Wahrheit: Die meisten Umgebungen kennen ihre Software-Lieferkette nur bruchstückhaft. Paketmanager ziehen transitiv nach, CI/CD verteilt fleißig, und niemand merkt, wenn ein Baustein vergiftet wurde. Wer das Risiko wirklich senken will, braucht drei Dinge: vollständige SBOM, harte Richtlinien für Supply-Chain-Security und ein Betrieb, der Updates und Blocklisten konsequent durchzieht – nicht diskutiert.

Warum Lieferketten so angreifbar sind

• Abhängigkeiten explodieren: Ein einzelner Service bringt schnell hunderte transitive Pakete mit.
• Vertrauensvorschuss: Registries und Mirrors werden stillschweigend als „okay“ behandelt.
• Angriffsvektoren: Typosquatting, Dependency-Confusion, übernommene Maintainer-Konten, bösartige Post-Install-Skripte, vergiftete Build-Images, geleakte CI-Secrets.
• Sichtbarkeit fehlt: Ohne SBOM und Provenance-Nachweise erkennt niemand, was tatsächlich läuft – und wo zu patchen ist.

Kurz: Nicht das einzelne „böse Paket“ ist das Problem, sondern fehlende Beweisführung entlang der Kette.

Mindestkontrollen, die sofort wirken

1. SBOM als Betriebsunterlage, nicht als PDF-Deko

   • Generiert SBOMs pro Service und Build (nicht nur pro Repo).
   • Versioniert im Artifact-Store, verknüpft mit Tickets/Änderungen.
   • Verweist auf Lizenzen, CVE-Status, Kritikalität und Owner.

2. Repository-Hygiene & Paket-Policy

   • Allowlist der Registries, Namespaces und Signaturen.
   • Striktes Version-Pinning; kein „latest“.
   • Blocklisten für bekannte Schadbibliotheken, automatisches Fail-Build.
   • Secret-Scanning und Commit-Signaturen in allen Repos.

3. Provenance & Integrität

   • Nachweise für „wer hat was wann gebaut“ (z. B. Attestierungen auf Artefakten).
   • Reproduzierbare Builds, unveränderliche Artefakt-Hashes, Vier-Augen-Freigaben in CI/CD.
   • Minimalrechte für Build-Tokens, kurze Laufzeiten, Rotation erzwingen.

4. Update-Betrieb statt Update-Hoffnung

   • Automatisierte Dependency-PRs mit Risiko-Labeling.
   • Fix-SLOs nach Exponierung (Internet vs. intern) und Kritikalität.
   • „Break-Glass“-Pfad für schnelles Zurückrollen inklusive Canary-Stufen.

KPIs, die Reife sichtbar machen

• SBOM-Abdeckung: % Services mit aktueller SBOM (Build-genau, ≤7 Tage alt).
• Time-to-Upgrade: Median-Zeit bis Patch für kritische Libs (Internet-exponiert vs. intern).
• Pinned-Rate: Anteil hart gepinnter Abhängigkeiten ohne Wildcards.
• Provenance-Quote: % Artefakte mit signierter Herkunft und Hash-Nachweis.
• Blocklist-Treffer: Anzahl verhinderter Builds durch Policy – ja, „Fehlschläge“ sind hier ein gutes Zeichen.
• Secret-Leaks: Funde pro Monat, Zeit bis Rotation.

Diese Metriken gehören in das gleiche Steering wie MTTD/MTTR – sonst bleibt Lieferkettensicherheit Folklore.

90-Tage-Plan (pragmatisch, ohne Vendor-Bindung)

Tag 0–15 – Inventar & Policy

• Services inventarisieren, kritische Pfade markieren (Auth, Payment, Admin).
• Paket-Policy definieren: erlaubte Registries, Namespaces, Signaturen, Pinning-Regeln, Blocklisten.
• CI/CD-Secrets sichten: Rechte reduzieren, Laufzeiten verkürzen, Rotation planen.

Tag 16–45 – Sichtbarkeit & Stop-Kriterien

• Build-integrierte SBOM-Erzeugung aktivieren und in den Artifact-Store schreiben.
• Provenance-Atteste und Artefakt-Hashes verpflichtend machen; Build bricht bei Fehlen ab.
• Secret-Scanning und Commit-Signaturen aktivieren; Fail-Build bei Fund/Unsigned.

Tag 46–75 – Fix-Betrieb & Übung

• Automatisierte Update-PRs einschalten; Risiko-Labeling (Kritikalität/Exposure) hinterlegen.
• Fix-SLOs technisch erzwingen (z. B. Auto-Escalation bei Verzug).
• Drill: Simulierter bösartiger Paket-Fund → Block, Rollback, Post-Mortem mit Zeiten.

Tag 76–90 – Verankern & Verträge

• KPIs gegen Baseline spiegeln, Maßnahmen nachziehen.
• Vertragliche Mindestanforderungen in der Supply-Chain-Security: SBOM-Lieferpflicht, Notfall-Kontaktweg 24/7, Meldefristen, Drill-Teilnahme.
• Lessons Learned in Policy & Pipelines zurückspielen.

Governance ohne Theater

• Ein Source of Truth: SBOM, Policy-Files, Atteste, Blocklisten – zentral, versionsgeführt, revisionssicher.
• „No evidence, no deploy“: Kein Release ohne SBOM und Provenance.
• N-Tier-Sicht: Kritische Sub-Dienstleister liefern ebenfalls SBOM/Atteste – sonst kein Zugriff auf Kernpfade.
• Security als Gate im SDLC: Ohne bestandenes Gate kein Go-Live, auch wenn die Feature-Deadline drückt.

Fazit: Beweise statt Bauchgefühl

Die Software-Lieferkette wird nur so sicher, wie ihre Belege belastbar sind. Mit sauberer SBOM, harter Paket-Policy, signierter Provenance und durchgesetzten Fix-SLOs sinkt das Risiko – und zwar messbar. Open Source bleibt ein Wettbewerbsvorteil, wenn ihr die Regeln durchsetzt. Sonst ist es eine Einladung.