Das Image wurde eingespielt, dann schlug das IDS an. Warum wir jedes Image prüfen.
Ein Kundenimage wurde ausgerollt, Minuten später schlug das IDS an. Wie wir die Software-Lieferkette so prüfen, dass so etwas nicht mehr in Produktion landet.
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.
Warum das kein Einzelfall mehr ist
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: Typosquatting in Paketmanagern, kompromittierte Maintainer-Accounts, manipulierte Post-Install-Skripte, verdeckt eingeschleuste Krypto-Miner in Base-Images. Keine davon ist ein Null-Day-Drama. Alle zusammen sind der Grund, warum das IDS irgendwann etwas meldet, das niemand angefordert hat.
Was „Prüfung“ in der Praxis bedeutet
Prüfung heißt in der Supply-Chain-Welt nicht mehr „Virus-Scan auf dem Artefakt“. Prüfung heißt: Jede Stufe der Herkunft belegbar machen und auf dem Weg in Ihre Produktion mehrfach überprüfen. Konkret sprechen wir über vier Bausteine, die in einer reifen DevSecOps-Pipeline zusammenwirken:
Signaturverifikation über Sigstore / 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 setzt das hart durch.
SBOM — Software Bill of Materials. Jedes Build-Artefakt trägt eine maschinenlesbare Stückliste seiner Komponenten. 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.
Provenance nach SLSA. Die Herkunft eines Artefakts wird maschinenlesbar dokumentiert: welcher Commit, welcher Runner, welche Parameter. Das ist der Unterschied zwischen „wir glauben, das Image kommt von uns“ und „wir können beweisen, dass es von uns kommt“.
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, nicht nur zum Deploy-Zeitpunkt.
Warum das nicht optional ist
Die Argumente für diese Maßnahmen waren vor fünf Jahren vor allem technisch. Heute sind sie zusätzlich regulatorisch. NIS2 verlangt für wesentliche und wichtige Einrichtungen ein nachvollziehbares Management von Lieferkettenrisiken. Der Cyber Resilience Act macht Software-Herstellerinnen und -Hersteller für die Sicherheit ihrer Produkte entlang ihres gesamten Lebenszyklus verantwortlich. Beide verlangen am Ende dasselbe: Sie müssen beweisen können, was in Ihrer Software steckt und wie es dahin gekommen ist. Ohne Signaturen, SBOM und Provenance ist dieser Beweis nicht zu führen — jedenfalls nicht in einer Form, die einem Auditor standhält.
Wie wir das aufsetzen
In unserem DevSecOps as a Service-Betrieb ist Supply-Chain-Security kein Zusatzpaket, sondern Teil des Standard-Setups. Wir integrieren cosign, SBOM-Generierung und Vulnerability-Scans in die bestehende Pipeline, hängen einen Admission Controller in den Cluster und bauen ein einfaches Dashboard, das zeigt, was gerade läuft und ob es dort laufen darf. Das ist kein revolutionäres Re-Engineering, sondern ein paar disziplinierte Leitplanken, die Sie einmal sauber setzen und dann konsequent einhalten.
Und ja, beim ersten Durchlauf findet das Setup fast immer etwas. Eine alte Basis, ein vergessenes Sidecar, eine Abhängigkeit, die längst deprecated ist. Das ist kein Versagen Ihres Teams — es ist das Ergebnis einer Architektur, in der niemand die Lieferkette als Produkt verstanden hat. Sobald sie Produkt ist, wird sie auch gewartet.
Wenn es bei Ihnen gerade brennt
Wenn Sie diesen Text lesen, weil bei Ihnen gerade ein IDS-Alarm aufgelaufen ist, brauchen Sie kein Beratungsangebot, sondern Soforthilfe. Kai Ole Hartwig, der Gründer von Moselwal, berät in akuten Sicherheitsfragen persönlich und 1:1 unter seinem Angebot OnlyOle. Das ist der schnelle Weg an einen erfahrenen Ansprechpartner, ohne Agentur-Overhead, ohne Angebotsphase. Die Umsetzung einer vernünftigen Lieferketten-Pipeline setzen wir anschließend strukturell über Moselwal auf, in den meisten Fällen innerhalb weniger Wochen.
Lassen Sie uns strukturell sprechen
Wenn Sie Ihre Pipeline dauerhaft so aufstellen wollen, dass das IDS künftig weniger zu tun hat, lohnt sich ein nüchternes Gespräch über Ihren Ist-Stand und die nächsten zwei bis drei Schritte. 30 Minuten, kein Pitch. Wir schauen uns gemeinsam Ihre Build-Chain an und zeigen Ihnen, wo die schnellsten Gewinne liegen und was guten Gewissens später kommt.
Häufige Fragen
Was uns Kundinnen und Kunden zum Thema Lieferkettensicherheit am häufigsten fragen — offen beantwortet.
Wir nutzen nur offizielle Base-Images. Reicht das nicht?+
Offizielle Base-Images sind besser als irgendwelche Community-Builds, aber sie sind keine Garantie. Sie enthalten weiterhin Abhängigkeiten aus dritter Hand, sie werden gelegentlich kompromittiert, und sie altern — ein im Januar sauberes Image kann im April längst neue CVEs haben. Signaturprüfung, SBOM und kontinuierliche Nachprüfung gelten deshalb auch für offizielle Images, nicht nur für externe.
Was kostet ein Image-Scan pro Deploy?+
In Sekunden gerechnet: meist unter einer Minute pro Build. In Lizenzen gerechnet: überraschend wenig, weil die ausgereiften Werkzeuge (cosign, Trivy, Syft) Open Source sind und nur bei Enterprise-Add-ons Kosten entstehen. Der größere Posten ist die einmalige Integration, nicht der laufende Betrieb. Wir kalkulieren typischerweise einen fünfstelligen Einrichtungsaufwand und einen deutlich niedrigeren monatlichen Betriebsaufwand.
Was passiert, wenn der Scan anschlägt — blockiert das unsere Releases?+
Ja, bei harten Funden. Das ist die Idee eines Gates. Gleichzeitig regeln wir mit Ihnen vorher, was als „hart“ gilt und was nicht: Kritische CVEs ohne Fix blockieren. Mittlere Funde mit definierter Remediation-Frist laufen als Warnung durch. Informational-Funde werden geloggt, aber nicht gebremst. Entscheidend ist, dass diese Grenzlinien gemeinsam gezogen werden, bevor der erste Stopp passiert — nicht in der Hitze eines blockierten Release-Tages.
Können wir das ex post nachrüsten, ohne die Pipeline komplett umzubauen?+
Ja. Wir bauen in der Regel nicht um, wir hängen rein. cosign und Trivy integrieren sich als zusätzliche Pipeline-Stages in fast jede CI-Umgebung. Der Admission Controller im Cluster läuft parallel zu bestehenden Deployments. Die ersten Ergebnisse sehen Sie oft nach zwei bis drei Tagen, die vollständige Absicherung nach zwei bis drei Wochen — abhängig davon, wie viele unerwartete Altlasten der erste Scan hervorholt.
Wie verhält sich das zu NIS2 und CRA — ist das dasselbe?+
NIS2 und CRA adressieren denselben Bereich aus unterschiedlichen Winkeln. NIS2 verlangt von betroffenen Einrichtungen ein nachvollziehbares Risikomanagement ihrer Lieferkette. Der CRA verlangt von Produktherstellern Sicherheit über den gesamten Lebenszyklus ihrer Software, einschließlich Updates. Die technischen Bausteine — Signaturen, SBOM, Provenance, Nachprüfung — erfüllen zentrale Anforderungen beider Regelwerke. Wer das sauber aufsetzt, löst beide Pflichten in einer Bewegung.