Das Image wurde eingespielt, dann schlug das IDS an. Warum wir jedes Image prüfen.

TL;DR — die 90-Sekunden-Zusammenfassung

Das Muster

Container-Image läuft durch die Pipeline, IDS schlägt im Cluster an — Traffic, den niemand angefordert hat

Die Ursache

Build-Ergebnis wird geprüft, Code aus dritter Hand (Base-Images, Sidecars, Helm-Charts) als gegeben hingenommen

Prüfungs-Bausteine

Signatur-Verifikation (Sigstore/cosign), SBOM (CycloneDX), Provenance (SLSA), kontinuierliche Nachprüfung

Hartstopp

Admission Controller im Cluster setzt „ohne Signatur kein Deploy“ durch — keine Ausnahmen

Regulatorischer Anker

NIS-2 verlangt Lieferketten-Risikomanagement, CRA macht Hersteller für ihre Software entlang des gesamten Lebenszyklus haftbar

Erste Iteration

findet fast immer etwas — eine alte Basis, ein vergessenes Sidecar, eine deprecated Abhängigkeit. Das ist kein Versagen, das ist die Diagnose

 

Was ist das Problem?

Es ist eines der teuersten Szenarien moderner IT-Organisationen und zugleich eines der häufigsten: Ein Container-Image läuft durch die Pipeline, wird im Cluster aktiviert, und wenige Minuten später schlägt das IDS an. Im Container ist Traffic sichtbar, den niemand erwartet hat und der nichts mit dem eigenen Code zu tun hat. Was danach beginnt, ist selten die spektakuläre Krise mit Nachtschicht. Es ist eher die stille Anamnese in den Meetings der folgenden Tage: Woher kam das, wie ist es reingekommen, warum hat die Pipeline das nicht vorher gemeldet?

Dieses Muster sehen wir in Aufnahmegesprächen mit mittelständischen IT-Teams regelmäßig. Es ist fast immer die Folge eines blinden Flecks, der für sich genommen harmlos aussieht, in Summe aber jede Lieferkette angreifbar macht: Das eigene Build-Ergebnis wird gründlich geprüft. Der Code, den die Pipeline von außen holt (Base-Images, Abhängigkeiten, Sidecars, Helm-Charts), wird als gegeben hingenommen. Damit verschiebt sich die Vertrauensgrenze unbemerkt von Ihrem Repository an Dutzende fremder Registries, an Hunderte fremder Maintainer und an alles, was in deren Build-Pipelines passiert.

Auswirkungen: jede Stufe ist ein Übergabepunkt

Jede der genannten Stufen — Base-Image, Paketabhängigkeit, Sidecar, Helm-Chart — ist ein Übergabepunkt, an dem Code aus dritter Hand in Ihre Infrastruktur gelangt. Die Angriffe auf diese Übergabepunkte werden professioneller, nicht spektakulärer.

Wo die Angriffe heute sitzen

• Typosquatting in Paketmanagern — dasselbe Muster wie im npm-EVM/DeFi-Cluster vom 6. Mai
• Kompromittierte Maintainer-Accounts — wie beim Bitwarden-CLI-Vorfall vom 22. April
• Manipulierte Post-Install-Skripte in npm- und pip-Paketen
• Verdeckt eingeschleuste Krypto-Miner in Base-Images — ein Dauerthema in Docker Hub und Quay
• Manipulierte Distributionspfade ohne Quellcode-Kompromittierung — die seit drei Jahren dominante Klasse

Keine davon ist ein Null-Day-Drama. Alle zusammen sind der Grund, warum das IDS irgendwann etwas meldet, das niemand angefordert hat.

Wer ist betroffen?

Im Kern: jeder Mittelstand, der Container in Produktion betreibt — ob auf Kubernetes, Nomad, ECS oder einer Docker-Swarm-Insel. Drei Konstellationen sind besonders exponiert.

• Setups mit gemischter Base-Image-Strategie — ein Build zieht Debian-, Alpine-, Wolfi- und Ubuntu-Images aus drei verschiedenen Registries. Audit-Fähigkeit nahe null.
• Setups mit Helm-Charts aus Drittquellen — ein helm install mit fremdem Repository fügt unbeobachtet Dutzende Container-Images in den Cluster ein. Sichtbar ist meist nur das primäre Workload-Image.
• Setups mit aktiver Sidecar-Strategie — Istio, Linkerd, Datadog-Agents, ELK-Sidecars. Jeder Sidecar ist ein eigener Distributionspfad. Wer den nicht aktiv verifiziert, hat ihn auch nicht unter Kontrolle.

Wer ausschließlich self-built Base-Images aus einer einzigen internen Registry betreibt, ist deutlich weniger exponiert — hat dafür aber eine andere Pflicht: die Sauberkeit dieser Registry beweisen zu können.

Mitigation und Sofortmaßnahmen — vier Bausteine

Quick-Start in der Reihenfolge, in der wir Pipelines aktuell durchziehen — jeder Baustein schlägt eine bestimmte Klasse von Vorfällen ab.

# Quick-Prüfung eines Images auf Signatur und SBOM
cosign verify --certificate-identity-regexp=".*" \
  --certificate-oidc-issuer-regexp=".*" \
  registry.example.com/app:v1.2.3
syft registry.example.com/app:v1.2.3 -o cyclonedx-json > sbom.json
grype sbom:sbom.json

1. Signaturverifikation über Sigstore und cosign

Jedes Image, das in Produktion darf, hat eine kryptografische Signatur von einem benannten Identitätsanbieter. Ohne gültige Signatur kein Deploy. Punkt. Der Admission Controller im Cluster (Kyverno, Connaisseur oder Sigstore Policy Controller) setzt das hart durch. Keine Ausnahmen, auch nicht für „kurz mal eben“-Deploys.

2. SBOM, Software Bill of Materials

Jedes Build-Artefakt trägt eine maschinenlesbare Stückliste seiner Komponenten — idealerweise CycloneDX. Wenn morgen eine neue CVE auftaucht, wissen Sie in Minuten, welche Ihrer laufenden Workloads betroffen sind. Ohne SBOM wissen Sie es in Tagen oder gar nicht. Dependency-Track als Open-Source-Empfänger reicht völlig.

3. Provenance nach SLSA

Die Herkunft eines Artefakts wird maschinenlesbar dokumentiert: welcher Commit, welcher Runner, welche Parameter, welche Umgebung. Das ist der Unterschied zwischen „wir glauben, das Image kommt von uns“ und „wir können beweisen, dass es von uns kommt“. SLSA Level 2 als realistischer Mittelstand-Anfang, Level 3 als Reifegrad-Ziel.

4. Kontinuierliche Nachprüfung

Ein Image, das heute sauber ist, ist in sechs Wochen möglicherweise ein CVE-Kandidat. Unsere Pipeline prüft laufende Workloads daher täglich gegen aktualisierte Vulnerability-Datenbanken (Trivy, Grype, Snyk), nicht nur zum Deploy-Zeitpunkt. Sichtbar in einem Dashboard, das auch Nicht-Techniker lesen können.

Detection und Prüfung

Fünf Kernfragen, mit denen Sie in einer halben Stunde wissen, wo Ihre Lieferkette heute Klartext-Lücken hat.

• Welche Base-Images laufen heute in Produktion — Distribution, Tag, Digest? kubectl get pods -A -o jsonpath='{..image}' als 1-Liner, dann Inventur.
• Welche dieser Images haben eine cosign-Signatur, die Sie heute verifizieren können?
• Welche dieser Images haben eine SBOM, die Sie heute lesen können — oder existiert die nur im Build-Artefakt-Speicher der Pipeline?
• Welche Sidecars und Init-Container laufen, ohne dass jemand sie im Helm-Chart oder Manifest aktiv freigegeben hat?
• Wer im Team kann in 10 Minuten beantworten, ob ein heute publiziertes CVE überhaupt einen Ihrer Workloads trifft?

Quick-Check, den wir vor jedem Audit fahren:

# Alle distinct laufenden Images im Cluster
kubectl get pods --all-namespaces \
  -o jsonpath='{range .items[*]}{range .spec.containers[*]}{.image}{"\n"}{end}{end}' \
  | sort -u

# Signatur-Prüfung pro Image
for img in $(cat images.txt); do
  cosign verify "$img" > /dev/null 2>&1 \
    && echo "OK $img" || echo "FAIL $img"
done

Betreiberempfehlung

Was für welches Setup operativ stehen sollte — abhängig vom heutigen Reifegrad.

• Wenn Ihr Cluster heute Images aus mehr als einer Registry ohne Signatur-Prüfung zulässt — dann ist ein Kyverno- oder Connaisseur-Admission-Controller im Audit-Modus die nächste Sprint-Aufgabe. Audit-Modus heisst: noch nicht blockieren, aber sichtbar machen, was alles ohne Signatur läuft.
• Wenn Sie heute keine SBOMs erzeugen — dann ist syft oder Trivy SBOM-Output in der Build-Pipeline ein 2-Stunden-Job. Dependency-Track als Empfänger läuft auf einem kleinen Server.
• Wenn Sie SLSA noch nicht kennen — dann ist GitHub-Actions-Provenance oder die GitLab-CI-Komponente von Sigstore der pragmatische Einstieg. Level 2 ist realistisch in zwei Sprints, Level 3 ist Ziel für das nächste Halbjahr.
• Wenn Sie kontinuierliche Scans noch nicht haben — dann ist Trivy Operator im Cluster als Tageslauf ein Einstieg ohne neue Lizenzkosten. Snyk oder Aqua sind die Enterprise-Pfade.
• Wenn Sie unter NIS-2 oder CRA fallen — dann ist die Audit-Fähigkeit, welche Komponenten in welchem Image laufen, regulatorisch Pflicht. Ohne SBOM und Provenance ist diese Pflicht nicht erfüllbar.

Cross-Referenzen: der npm-EVM-Cluster-Beitrag für Mirror-Topologien, der Bitwarden-Beitrag für Pipeline-Disziplin im Detail, der CI/CD-Verdichtungs-Beitrag für die strukturelle Argumentation.

Fazit

Lieferkettensicherheit ist kein Add-on, das man im nächsten Quartal evaluiert. Sie ist die Grundlage dafür, dass das, was bei Ihnen läuft, auch das ist, was Sie laufen lassen wollten. Vier Bausteine — Signatur, SBOM, Provenance, kontinuierliche Prüfung — ergeben in Summe eine Pipeline, die das nächste IDS-Ereignis nicht als Überraschung erlebt, sondern als bereits inventarisierten Befund.

Die Frage lautet nicht, ob das nächste manipulierte Image kommt. Sie lautet, ob Ihre Pipeline es vor dem IDS bemerken würde — und ob Sie nach dem Bemerken in derselben Stunde wissen, welche Workloads auf welcher Komponente in welcher Version stehen. Mit den vier Bausteinen geht die Antwort von „hoffentlich“ auf „in zwei Befehlen“.

Eine längere Aufarbeitung mit konkreten Beispielen unserer DevSecOps-Pipeline, der Admission-Controller-Konfiguration und der Dependency-Track-Integration findet sich unter ole-hartwig.eu.