Bildquelle: extern
Artifact Signing im CI/CD-Betrieb: Welche 5 Kontrollpunkte DevOps-Teams bei Images und Attestations jetzt fest verdrahten sollten
Viele DevOps-Teams haben ihre Build-Pipelines in den vergangenen Jahren deutlich automatisiert, aber die Vertrauenskette zwischen Quellcode, Build, Registry und Laufzeitumgebung bleibt oft erstaunlich löchrig. Ein Container-Image wird erfolgreich gebaut, in eine Registry geschoben und später in Kubernetes ausgerollt, ohne dass unterwegs verlässlich geprüft wird, wer das Artefakt erzeugt hat, welcher Workflow dahinterstand und ob das ausgerollte Image wirklich aus der vorgesehenen Pipeline stammt. Genau an dieser Stelle wird Artifact Signing vom Spezialthema zur Betriebsaufgabe.
Sigstore beschreibt mit Cosign ein Modell, bei dem Signaturen nicht mehr nur an langlebigen Schlüsseln hängen müssen. Stattdessen können kurzlebige Zertifikate, OIDC-Identitäten und der Transparenzdienst Rekor genutzt werden, um Signaturereignisse nachvollziehbar zu machen. Zusammen mit Attestations, also maschinenlesbaren Nachweisen über Build-Prozess, Herkunft oder Prüfungen, entsteht daraus ein Betriebsmodell, das deutlich robuster ist als ein bloßes „Image liegt in unserer Registry, also wird es schon passen“.
Für 2026 reicht es deshalb nicht mehr, Cosign einmal testweise in eine Pipeline zu schrauben. Entscheidend sind fünf Kontrollpunkte, die Signing, Verifikation, Deployment und Ausnahmewege zusammenbringen.
1. Nicht Tags, sondern unveränderliche Digests zum eigentlichen Freigabeobjekt machen
Der erste Fehler passiert oft schon vor der Signatur. In vielen Umgebungen werden Images weiterhin über Tags wie latest, prod oder release-2026 referenziert. Für den Betrieb ist das zu weich. Wenn Artefakte verlässlich signiert und später überprüft werden sollen, muss die Organisation ihr Freigabeobjekt auf den unveränderlichen Digest verlagern. Nur dann ist klar, welches konkrete Image gebaut, signiert, geprüft und ausgerollt wurde.
Praktisch heißt das: Die CI/CD-Pipeline sollte nach dem Build den Digest erfassen, genau diesen signieren und genau diesen in Promotion-, Deployment- und Rollback-Prozessen weiterreichen. Tags dürfen weiter für Bedienkomfort oder Lesbarkeit existieren, aber nicht als eigentliche Vertrauensbasis. Sonst prüft das Team im Zweifel eine Signatur auf einem Artefakt, das später über einen geänderten Tag gar nicht mehr identisch referenziert wird.
Gerade in hektischen Release-Fenstern ist dieser Punkt wichtiger, als er klingt. Wer Digests zur verbindlichen Referenz macht, reduziert Missverständnisse zwischen Build-Team, Plattformbetrieb und Incident-Response sofort.
2. Festlegen, welche Identitäten überhaupt signieren dürfen, statt nur „irgendwelche Signaturen“ zu akzeptieren
Sigstore erklärt das keyless-Modell sehr klar: Fulcio stellt kurzlebige Zertifikate aus, die eine OIDC-Identität an ein ephemeres Schlüsselpaar binden, und Rekor protokolliert das Signaturereignis. Der eigentliche Gewinn liegt aber nur dann vor, wenn das Betriebsteam die zugelassenen Identitäten sauber eingrenzt. Eine vorhandene Signatur allein ist wertlos, wenn niemand definiert hat, welche Workflows, Repositories oder Service-Accounts überhaupt autorisiert sind.
Deshalb sollte jede Organisation für produktive Artefakte ein Signaturmodell mit klarer Policy festlegen. Dazu gehören mindestens drei Fragen: Welche CI-Systeme dürfen produktive Images signieren, welche OIDC-Issuer werden akzeptiert, und welche Identitätsmerkmale müssen bei der Verifikation passen, etwa Repository, Workflow oder Service-Konto? Cosign unterstützt genau diese Art der identitätsbasierten Verifikation.
In der Praxis trennt diese Regel saubere Lieferketten von bloßem Sicherheitsdekor. Wer nur prüft, dass etwas signiert ist, baut eine Scheinsicherheit auf. Wer prüft, von wem und unter welchen Bedingungen signiert wurde, bekommt einen belastbaren Kontrollpunkt.
3. Verifikation an mehreren Gates erzwingen, nicht erst kurz vor Produktion
Ein häufiger Reifegradfehler ist, dass Teams zwar signieren, aber kaum verifizieren. Dann existiert ein hübscher kryptografischer Nachweis, der im Alltag faktisch folgenlos bleibt. Sigstore betont selbst, dass der eigentliche Sicherheitswert erst bei der Verifikation entsteht. Genau deshalb braucht der Prozess mehrere Gates.
Mindestens drei Stellen sind sinnvoll. Erstens sollte schon bei Promotion zwischen Registry-Stufen oder Umgebungen geprüft werden, ob Signatur, Zertifikatsidentität und erwarteter Digest zusammenpassen. Zweitens sollte die Deploymentschicht nur referenzierte Artefakte zulassen, die diese Prüfung bereits bestanden haben. Drittens lohnt sich in Kubernetes ein zusätzlicher Admission-Check. Der Sigstore Policy Controller kann Signaturen und Attestations auf Namespace-Basis prüfen und zwischen Warnen und Erzwingen unterscheiden.
Für den Betrieb ist das Gold wert, weil sich damit Fehler früher abfangen lassen. Ein falsch gebautes oder falsch referenziertes Image muss nicht erst im Cluster auftauchen, um als Problem sichtbar zu werden. Ebenso wichtig: Verifikation sollte stufenweise eingeführt werden. Erst Sichtbarkeit und Warnmodus, dann Enforce für ausgewählte Namespaces oder kritische Workloads. So verhindert das Team, dass gut gemeinte Supply-Chain-Kontrollen beim ersten Altlast-Fund den Betrieb abrupt blockieren.
4. Attestations und Provenance zum Pflichtnachweis für produktive Promotion machen
Signing beantwortet vor allem die Frage, ob ein Artefakt zu einer bestimmten Identität und Signaturkette passt. Für viele Betriebsentscheidungen reicht das nicht. Wer produktive Software freigibt, will zusätzlich wissen, wie das Artefakt gebaut wurde, welche Eingaben in den Build geflossen sind und ob der Build-Prozess selbst vertrauenswürdig war. Genau hier kommen Provenance und Attestations ins Spiel.
Die SLSA-Spezifikation beschreibt diese Reifestufen sehr greifbar. Schon Build Level 1 fordert vorhandene Provenance, also Nachweise darüber, wie ein Paket gebaut wurde. Höhere Stufen erhöhen dann die Vertrauenswürdigkeit, etwa durch signierte Provenance und stärkere Absicherung der Build-Plattform. Für DevOps-Teams ist die wichtigste praktische Lehre: Nicht jede Pipeline muss sofort höchste Reife erreichen, aber produktive Promotion ohne irgendeinen Herkunftsnachweis ist 2026 kaum noch vertretbar.
NISTs Secure Software Development Framework liefert dafür den passenden Management-Rahmen. Es geht nicht nur darum, weniger Schwachstellen zu produzieren, sondern auch darum, mit Lieferanten, Auditoren und internen Stakeholdern eine gemeinsame Sprache für sichere Entwicklungs- und Freigabepraktiken zu haben. Im Alltag bedeutet das: Ein Release sollte nicht allein deshalb nach Produktion wandern, weil Tests grün sind. Es sollte zusätzlich belegbar sein, aus welchem Workflow das Artefakt stammt, welche Prüfungen gelaufen sind und ob dieser Nachweis zur eigenen Mindestpolitik passt.
5. Ausnahmewege, Policy-Rollout und Incident-Nutzung vorab regeln
Der fünfte Kontrollpunkt wird gern verdrängt, entscheidet im Ernstfall aber über die Akzeptanz des gesamten Modells. Artifact Signing scheitert selten an Kryptografie, sondern an schlecht geregelten Ausnahmefällen. Was passiert, wenn ein dringend benötigter Hotfix aus einem Legacy-Repo kommt, das noch keine Attestations erzeugt? Wie lange darf ein Warnmodus laufen? Wer darf eine Policy temporär lockern? Und wie erkennen On-Call-Teams, dass ein Deploy gerade an fehlender Provenance statt an einem Clusterproblem scheitert?
Deshalb brauchen Teams ein dokumentiertes Betriebsmodell mit klaren Ausnahmewegen. Dazu gehören ein Break-Glass-Prozess mit Freigabeverantwortung, protokollierte befristete Ausnahmen und Runbooks für Incident- und Change-Teams. Ebenso wichtig ist ein sichtbarer Migrationspfad: erst Monitoren, dann Warnen, dann Enforce, jeweils mit klarer Definition, welche Repositories oder Services wann unter welche Policy fallen.
Wer diese Governance nicht mitdenkt, erzeugt Reibung und Umgehungsverhalten. Wer sie sauber vorbereitet, macht aus Supply-Chain-Sicherheit einen steuerbaren Betriebsprozess. Genau das ist der Unterschied zwischen einem Tool-Pilot und einem tragfähigen DevOps-Standard.
Fazit
Artifact Signing ist 2026 kein Randthema für besonders sicherheitsaffine Plattformteams mehr. Es wird zur Voraussetzung dafür, Software-Lieferketten überhaupt belastbar steuern zu können. Entscheidend sind dabei keine isolierten Einzelmaßnahmen, sondern ein geschlossenes Betriebsmodell: Digests statt bloßer Tags, klar definierte Signatur-Identitäten, mehrstufige Verifikation, verpflichtende Herkunftsnachweise und sauber geregelte Ausnahmewege.
Teams, die diese fünf Kontrollpunkte jetzt fest verdrahten, gewinnen nicht nur mehr Sicherheit. Sie bekommen auch bessere Freigabeentscheidungen, schnellere Ursachenklärung im Störfall und deutlich weniger Diskussionen darüber, ob ein Artefakt „eigentlich aus der richtigen Pipeline“ kam. Genau das ist in modernen CI/CD-Umgebungen der eigentliche Mehrwert.
