Bildquelle: Bildquelle: Pexels / Gustavo Galeano Maz / https://www.pexels.com/photo/a-person-holding-a-silver-and-black-door-lever-7522609/
Ohne Verifikation im Cluster endet Artefaktsignierung an der Registry
Viele Entwicklungs- und Plattformteams haben das Thema Software-Lieferkette inzwischen ernsthaft auf dem Tisch. Builds laufen auf gehärteten CI-Systemen, Container werden signiert, SBOMs entstehen automatisch, und erste Nachweise über Herkunft und Build-Prozess liegen vor. Auf dem Papier sieht das nach deutlichem Fortschritt aus. Im operativen Alltag endet der Sicherheitsgewinn aber oft genau an der Stelle, an der das Artefakt in die Registry geschoben wurde. Wenn später weder Deployment-Pipeline noch Admission Controller noch Laufzeitplattform prüfen, ob Image, Signatur und Herkunft wirklich zusammenpassen, bleibt Artefaktsignierung ein halber Schutzpfad.
Genau darauf weist SLSA sehr klar hin: Provenance nützt nichts, wenn sie niemand inspiziert. Für den Betrieb ist das die entscheidende Botschaft. Signaturen und Attestierungen sind keine Zierde für Audits, sondern nur dann wertvoll, wenn daraus echte Freigabe- und Ablehnungsentscheidungen entstehen. Sonst baut eine Organisation zwar Nachweise, aber keine durchgesetzte Vertrauenskette.
Der häufigste Fehler liegt nicht im Signieren, sondern im fehlenden Durchgriff
In vielen Umgebungen ist der erste Umsetzungsschritt naheliegend: Das Build-System erzeugt ein Container-Image, signiert es mit Cosign oder einem vergleichbaren Verfahren und hängt optional noch eine Attestierung oder SBOM an. GitHub unterstützt diesen Weg inzwischen direkt über Artifact Attestations in Actions. Auch Sigstore macht das Generieren und Verifizieren kryptografischer Nachweise deutlich zugänglicher als frühere, rein schlüsselbasierte Sonderwege.
Der operative Bruch kommt danach. Ein Deployment zieht später einfach das Image-Tag aus der Registry, Kubernetes startet den Pod, und niemand prüft mehr, ob das Artefakt wirklich von dem erwarteten Builder stammt, ob die Signatur zum Digest passt oder ob die Attestierung die richtigen Parameter beschreibt. Genau an dieser Stelle entsteht eine gefährliche Scheinsicherheit. Das Team kann zeigen, dass Signaturen existieren. Es kann aber nicht zeigen, dass unsignierte, falsch signierte oder aus einem unerwarteten Build-Kontext stammende Artefakte zuverlässig draußen bleiben.
SLSA beschreibt deshalb nicht nur, wie Provenance entstehen soll, sondern auch, was bei der Verifikation zu prüfen ist: Builder-Identität, Signatur, erwarteter Build-Typ, relevante Parameter und die Übereinstimmung zwischen Artefakt und Nachweis. Für IT-Betrieb und Plattformverantwortung heißt das praktisch: Die Sicherheitsarbeit ist nicht mit dem Signieren abgeschlossen. Sie beginnt erst dort, wo aus Nachweisen verbindliche Policy wird.
Build-Vertrauen und Laufzeit-Vertrauen müssen dieselbe Sprache sprechen
Ein typisches Problem in reiferen Delivery-Stacks ist die Trennung der Zuständigkeiten. Das CI/CD-Team richtet Signierung und Attestierungen ein. Das Plattformteam betreibt Cluster und Admission Controller. Security definiert vielleicht Richtlinien. Wenn diese drei Perspektiven nicht dieselben Vertrauensregeln verwenden, entstehen Lücken trotz guter Einzelmaßnahmen.
Ein Beispiel: Das Build-Team nutzt keyless Signierung mit einer bestimmten OIDC-Identität und erwartet Attestierungen aus genau einem Workflow. Das Plattformteam prüft im Cluster später aber nur, ob überhaupt irgendeine gültige Signatur vorhanden ist. Dann bleibt offen, von wem sie stammt. Umgekehrt kann Security eine Builder-Identität freigeben, während die Release-Pipeline weiterhin Images aus mehreren Nebenpfaden in dieselbe Registry schiebt. Das Ergebnis ist kein sauberer End-to-End-Pfad, sondern ein Gemisch aus lokalen Annahmen.
Sigstore zeigt bei der Verifikation bewusst, dass nicht nur ein Public Key geprüft werden sollte, sondern auch Identität und Aussteller. SLSA geht noch weiter und fordert, Builder-Identitäten mit einem definierten Root of Trust zu verknüpfen. Genau daraus folgt die Management-Aufgabe: Jede produktive Plattform braucht eine kleine, explizite Liste vertrauenswürdiger Build-Wege. Alles andere mag technisch signiert sein, sollte aber nicht automatisch deploybar sein.
Admission Controller sind der operative Wendepunkt
Solange Verifikation nur als optionaler CLI-Schritt in einem Security-Playbook steht, bleibt sie im Alltag zu leicht umgehbar. Erst wenn Registry-, Deployment- oder Admission-Punkte verbindlich prüfen, wird aus Supply-Chain-Sicherheit ein Betriebsmechanismus. Kyverno zeigt das sehr konkret mit verifyImages-Policies: Ein Cluster kann die Signatur eines Images gegen definierte Attestoren prüfen und den Start verweigern, wenn die Vertrauenskette nicht stimmt.
Wichtig ist dabei, dass Teams nicht bei einem reinen Ja-Nein-Signaturcheck stehen bleiben. Für produktive Freigaben tragen meist drei Fragen: Erstens stammt das Artefakt von einem zugelassenen Builder oder Workflow? Zweitens passt die Signatur zum konkreten Digest statt nur zu einem beweglichen Tag? Drittens liegen die erwarteten Metadaten oder Attestierungen vor, etwa zur Build-Herkunft oder SBOM? Wer nur das Vorhandensein irgendeiner Signatur kontrolliert, schließt die offensichtlichsten Lücken, aber nicht die relevanten Governance-Fragen.
Praktisch bewährt sich deshalb ein stufenweiser Einstieg. Zunächst lässt sich Verifikation im Audit-Modus sichtbar machen, um Abweichungen zu sammeln. Danach sollten produktive Namespaces oder besonders kritische Workloads auf Enforce umgestellt werden. Parallel braucht es einen klar dokumentierten Break-Glass-Weg für echte Störungen, damit Sicherheitsregeln den Betrieb nicht in blindes Umgehen treiben. Entscheidend ist nur: Der Ausnahmeweg muss sichtbar, eng begründet und nachgelagert auswertbar bleiben.
Tags, Digests und Ausnahmen entscheiden über die Alltagstauglichkeit
Viele Programme scheitern nicht an Kryptografie, sondern an Betriebsdetails. Wer weiter primär mit Tags wie latest oder unscharfen Release-Namen arbeitet, macht die Verifikation unnötig fragil. Signaturen und Attestierungen entfalten ihren Wert viel sauberer an festen Digests. Dasselbe gilt für die Verbindung zur Deployment-Dokumentation: Wenn ein Service Owner nicht nachvollziehen kann, welcher Digest in welcher Umgebung freigegeben wurde, wird jede spätere Incident- oder Audit-Frage wieder Handarbeit.
Auch Ausnahmen brauchen Disziplin. Es wird Fälle geben, in denen Drittanbieter-Images, Legacy-Komponenten oder dringende Hotfixes nicht sofort in den Idealpfad passen. Dann hilft kein Wegsehen. Besser ist ein expliziter Ausnahmeprozess mit Frist, Owner, Grund und geplantem Rückbau. Genau das hält die Lieferkettensicherheit glaubwürdig. Unsichtbare Sonderfreigaben zerstören sie schneller als eine offen dokumentierte Übergangslösung.
Attestierungen werden erst mit Release-Entscheidungen wertvoll
GitHub beschreibt Artifact Attestations zurecht als Herkunftsnachweis für Builds. Im Alltag ist das aber nur der Rohstoff. Der eigentliche Nutzen entsteht erst, wenn Release- und Deployment-Entscheidungen diese Nachweise auswerten. Ein Team kann zum Beispiel festlegen, dass produktive Deployments nur dann zulässig sind, wenn das Image aus dem freigegebenen Workflow stammt, die erwartete Attestierung vorhanden ist und die Signatur mit der definierten Identität verifiziert wurde. Ab dort wird eine Attestierung operativ relevant.
Das verändert auch die Zusammenarbeit zwischen DevOps, Security und Incident Response. Bei einem Verdacht auf kompromittierte Build-Pfade reicht es nicht mehr, hektisch nach Artefakten zu suchen. Stattdessen lässt sich systematisch prüfen, welche Images aus welchem Builder stammen, welche Umgebungen nur attestierte Digests akzeptieren und wo Ausnahmen offen sind. Genau dieser Transparenzgewinn ist der eigentliche Unterschied zwischen bloßem Signieren und belastbarer Vertrauenskette.
Fazit
Artefaktsignierung ist ein sinnvoller Anfang, aber noch keine durchgesetzte Supply-Chain-Sicherheit. Der Mehrwert entsteht erst dann, wenn Build, Registry, Deployment und Cluster dieselben Vertrauensregeln anwenden und Verstöße tatsächlich blockieren. SLSA, Sigstore, GitHub Attestations und Policy-Werkzeuge wie Kyverno liefern dafür die Bausteine bereits heute. Die operative Aufgabe liegt nicht in noch mehr Nachweisdateien, sondern darin, Verifikation an die Stellen zu bringen, an denen Freigaben entschieden werden. Ohne diesen Schritt endet Artefaktsignierung tatsächlich an der Registry.
