Build-Provenance im CI/CD: Welche 5 Nachweise DevOps-Teams 2026 verbindlich liefern sollten

Viele DevOps-Teams haben ihre Software-Lieferkette in den vergangenen zwei Jahren sichtbar verbessert. Container werden gescannt, Abhängigkeiten inventarisiert, SBOMs erzeugt und Secrets strenger behandelt. Trotzdem bleibt in vielen Organisationen eine unangenehme Lücke: Man weiß oft nicht belastbar genug, wo ein Artefakt gebaut wurde, welcher Workflow tatsächlich gelaufen ist und ob genau dieses Ergebnis später in Test, Registry oder Produktion angekommen ist. Genau an dieser Stelle wird Build-Provenance 2026 vom Security-Spezialthema zur Betriebsanforderung.

Das SLSA-Framework beschreibt den Kern des Problems sehr präzise. Es geht darum, die Integrität von Artefakten über die gesamte Software-Lieferkette hinweg abzusichern und nachvollziehbar zu machen, wie ein Paket entstanden ist. In der SLSA-Build-Logik reicht die Spanne von Build L1, bei dem Provenance überhaupt erst existiert, bis zu Build L3 mit gehärteter Build-Plattform und stärkerem Schutz gegen Manipulation während des Builds. NIST formuliert im Secure Software Development Framework denselben Bedarf aus Managementsicht: Sichere Entwicklungspraktiken sollen nicht nur Schwachstellen reduzieren, sondern auch eine gemeinsame Sprache für Produzenten, Käufer und Betreiber von Software schaffen. Für den Betriebsalltag heißt das sehr nüchtern: Wer Artefakte nicht sauber nachweisen und verifizieren kann, hat im Incident, im Audit und bei Lieferkettenrisiken ein Steuerungsproblem.

Für 2026 sind deshalb fünf Nachweise besonders wichtig.

1. Für kritische Artefakte muss Provenance überhaupt verbindlich existieren

Der erste Engpass ist oft banaler als gedacht. Viele Teams sprechen über Supply-Chain-Security, erzeugen aber nur für einen Teil ihrer Outputs verwertbare Nachweise. Ein Container-Image in der Registry bekommt vielleicht Metadaten, das parallel veröffentlichte Binary, Helm-Chart oder ZIP-Artefakt jedoch nicht. Genau das schwächt jede spätere Verifikation.

Praxistauglich ist deshalb nur ein klarer Scope. DevOps-Leads sollten festlegen, für welche Artefaktklassen Provenance verpflichtend ist, mindestens für produktionsrelevante Container-Images, deploybare Binärdateien, Infrastrukturpakete und idealerweise auch zugehörige SBOMs. GitHub beschreibt Artifact Attestations genau in diesem Sinne: Sie sollen belegen, wo und wie Software gebaut wurde. Wer diese Nachweise nur selektiv erzeugt, bekommt keine belastbare Kette, sondern einzelne Inseln.

Ein guter Kontrollpunkt ist die Release-Definition. Ein Release gilt dann nicht mehr als vollständig, wenn nur Build und Scan erfolgreich waren, sondern erst dann, wenn die geforderten Attestierungen für alle definierten Artefakte vorliegen.

2. Der Nachweis muss an eine definierte Build-Plattform gebunden sein, nicht an Vertrauen in einzelne Personen

Hier trennt sich saubere Lieferkettensicherheit von gut gemeinter Dokumentation. SLSA macht deutlich, dass höhere Sicherheitsstufen nicht allein auf vorhandener Provenance beruhen, sondern auf der Bindung an eine gehostete und später gehärtete Build-Plattform. Das ist für viele Teams eine unbequeme Wahrheit. Solange Builds je nach Projekt unterschiedlich, mit lokalen Sonderwegen oder in halboffiziellen Runnern entstehen, bleibt die Aussagekraft jedes Nachweises begrenzt.

Im Alltag bedeutet das: DevOps-Organisationen sollten definieren, welche Build-Systeme offiziell für produktionsrelevante Artefakte zugelassen sind, welche Runner-Typen genutzt werden dürfen, wie Identitäten für Signatur und Attestation entstehen und welche Berechtigungen Workflows dafür bekommen. GitHub nennt dafür beispielsweise explizite Rechte wie id-token: write und attestations: write. Das ist mehr als YAML-Kosmetik. Es zwingt Teams dazu, ihre Vertrauenskette technisch festzulegen.

Wer diesen Punkt sauber zieht, gewinnt gleich doppelt: Die Lieferkette wird robuster gegen Manipulation, und gleichzeitig sinkt die Zahl stiller Sonderfälle, die später niemand mehr erklären kann.

3. Verifikation muss vor Deployment stattfinden, nicht erst im Audit

Der häufigste Reifegradfehler lautet: Attestierungen werden erzeugt, aber kaum konsequent geprüft. Dann existiert Provenance zwar formal, sie hat im Tagesgeschäft jedoch kaum Wirkung. Genau hier lohnt die zweite Hälfte der Disziplin. GitHub verweist nicht nur auf die Generierung von Artifact Attestations, sondern auch auf deren Verifikation, bis hin zur Durchsetzung über einen Kubernetes Admission Controller. Das ist der operative Maßstab.

Praktisch heißt das: Vor dem Deployment in kritische Umgebungen muss automatisiert geprüft werden, ob das Artefakt eine erwartete Attestation besitzt, ob der Unterzeichner zur zugelassenen Build-Pipeline gehört und ob Workflow, Repository oder Build-Pfad zur definierten Policy passen. Wer möchte, kann streng anfangen, etwa zunächst nur für produktive Container-Images. Wichtig ist nicht die sofortige Perfektion, sondern dass Verifikation als Gate im Delivery-Prozess sichtbar wird.

Ohne diesen Schritt bleibt Provenance ein Bericht für Auditoren. Mit diesem Schritt wird sie zu einer echten Betriebsregel.

4. Ausnahmen brauchen einen gesteuerten Prozess, sonst unterlaufen sie die ganze Idee

Kaum eine Organisation startet ohne Altlasten. Es gibt Fremdartefakte von Herstellern, Legacy-Builds außerhalb der Standardpipeline, Migrationsprojekte oder dringende Hotfixes, bei denen der gewünschte Nachweis anfangs noch nicht vollständig vorliegt. Genau hier kippen viele Programme. Entweder wird die Policy so weich formuliert, dass sie nichts erzwingt, oder sie wird so hart ausgerollt, dass Teams sie inoffiziell umgehen.

Besser ist ein sauberer Ausnahmeprozess mit Ablaufdatum. Definieren Sie, welche Fälle vorübergehend ohne vollständige Provenance passieren dürfen, wer die Ausnahme genehmigt, wie das Restrisiko dokumentiert wird und bis wann der Zielzustand erreicht sein muss. Das ist klassische Betriebsdisziplin, nicht Bürokratie. In ITSM-Sprache gesprochen, gehört das in Change Enablement und Risikobewertung, nicht in individuelle Chat-Nachrichten zwischen Plattformteam und Entwicklergruppe.

Besonders wichtig ist die Trennung zwischen extern beschaffter Software und intern gebautem Code. Für Fremdkomponenten werden Teams oft nicht sofort dieselbe Beweislage bekommen wie für eigene Builds. Gerade deshalb müssen die Regeln explizit sein, sonst vermischt sich beides unsauber.

5. Provenance muss in Incident Review, Lieferantensteuerung und Audit-Nachweise zurückgespielt werden

Der fünfte Nachweis entscheidet darüber, ob das Thema dauerhaft trägt. Build-Provenance ist kein isoliertes DevSecOps-Feature. Ihr Wert entsteht erst, wenn andere Steuerungsroutinen sie nutzen. NIST betont im SSDF ausdrücklich, dass sichere Entwicklungspraktiken auch Kommunikation mit Lieferanten und Beschaffung unterstützen sollen. Genau das lässt sich im Betrieb direkt nutzen.

Wenn ein Sicherheitsvorfall auftritt, muss ein Team schnell sehen können, welche Artefakte betroffen sind, aus welchem Build sie stammen und ob der freigegebene Workflow tatsächlich verwendet wurde. Wenn eine Revision Nachweise verlangt, sollte die Antwort nicht aus Screenshots bestehen, sondern aus prüfbaren Build- und Verifikationsdaten. Und wenn Plattformteams interne Standards durchsetzen wollen, brauchen sie Kennzahlen, etwa den Anteil produktiver Artefakte mit gültiger Provenance, die Zahl temporärer Ausnahmen oder die Quote abgewiesener Deployments wegen fehlender Attestation.

Gerade für größere Unternehmen ist das der Punkt, an dem Lieferkettensicherheit vom Spezialwissen einzelner Engineers in ein steuerbares Führungsinstrument übergeht.

Was DevOps-Teams in den nächsten 90 Tagen konkret tun sollten

• Artefaktklassen festlegen: Entscheiden, für welche Outputs Provenance und Attestierungen Pflicht werden.
• Build-Plattform standardisieren: Zugelassene Runner, Workflows und Signaturpfade verbindlich definieren.
• Ein Verifikations-Gate einführen: Mindestens vor Produktion automatisiert prüfen, ob Attestierungen vorhanden und gültig sind.
• Ausnahmen formalisieren: Legacy- oder Fremdartefakte nicht stillschweigend durchwinken, sondern befristet und nachvollziehbar behandeln.
• Kennzahlen etablieren: Abdeckungsgrad, Ausnahmen und Policy-Verstöße monatlich sichtbar machen.

2026 reicht es für eine belastbare Software-Lieferkette nicht mehr, nur Schwachstellen zu zählen oder SBOMs abzulegen. Entscheidend ist, ob eine Organisation für ihre produktiven Artefakte glaubwürdig nachweisen kann, wie sie entstanden sind, wer sie freigegeben hat und ob nur erwartete Build-Wege in die Auslieferung gelangen. Build-Provenance ist damit kein zusätzlicher Luxus im CI/CD, sondern die Grundlage dafür, dass Security, Betrieb und Governance über dieselbe Realität sprechen.

Quellen

• SLSA: Überblick über Ziele und Nutzen zur Absicherung von Software-Artefakten
• SLSA v1.0: Build-Levels L1 bis L3 und ihre Anforderungen
• GitHub Docs: Artifact Attestations verwenden und verifizieren
• GitHub Docs: Build-Provenance für Binärdateien, Container und SBOMs erzeugen
• NIST SP 800-218: Secure Software Development Framework