Bildquelle: Bildquelle: Pexels / https://www.pexels.com/photo/photo-of-man-scanning-a-bucket-4484154/
SLSA braucht mehr als Signaturen: Verifizierte Provenance muss an reale Release-Gates anschließen
Viele DevOps- und Plattformteams haben in den letzten zwei Jahren sichtbare Fortschritte bei der Absicherung ihrer Build-Pipelines gemacht. Es werden SBOMs erzeugt, Container signiert, OIDC eingerichtet und erste Attestierungen an Artefakte gehängt. Trotzdem bleibt in vielen Umgebungen eine unangenehme Lücke offen: Die erzeugten Nachweise spielen bei der eigentlichen Release- und Deployment-Entscheidung kaum eine Rolle. Dann ist zwar dokumentiert, wie etwas gebaut wurde, aber die Freigabe prüft diesen Nachweis nicht verbindlich genug.
Genau hier wird SLSA relevant. Das Framework Supply-chain Levels for Software Artifacts soll helfen, Software-Lieferketten schrittweise gegen Manipulation, unklare Herkunft und schwache Build-Prozesse zu härten. Für IT-Leitungen ist das kein Nischenthema der Produktsicherheit mehr. Sobald Plattformteams interne Entwicklerportale, Container-Images, IaC-Module oder wiederverwendbare CI/CD-Workflows bereitstellen, wird die Frage nach belastbarer Herkunft zum Betriebs- und Governance-Thema.
Wer das Thema nur als neue Signaturpflicht behandelt, verfehlt deshalb den praktischen Nutzen. Eine Signatur sagt zunächst nur, dass irgendein Schlüssel oder Dienst ein Artefakt bestätigt hat. Für einen belastbaren Release-Prozess reicht das nicht. Entscheidend ist, ob Teams daraus eine verifizierbare Kette vom Quellcode über den Workflow bis zum ausgerollten Artefakt ableiten und diese Kette an echte Freigabegrenzen koppeln.
Attestierungen helfen erst, wenn sie vor dem Deployment geprüft werden
Die GitHub-Dokumentation zu Artifact Attestations formuliert einen wichtigen Punkt ungewöhnlich klar: Das Erzeugen von Attestierungen allein bringt noch keinen Sicherheitsgewinn. Erst die Verifikation macht den Unterschied. Dieser Hinweis ist für den Betriebsalltag zentral, weil viele Organisationen den ersten Teil des Wegs bereits gehen, den zweiten aber offenlassen. Sie bauen Attestierungen in die Pipeline ein, prüfen sie später jedoch höchstens stichprobenartig oder gar nicht mehr.
Im Release-Prozess entsteht dadurch eine trügerische Reife. Auf den Dashboards sieht man grüne Jobs, signierte Container und vielleicht sogar einen Provenance-Nachweis mit Repository, Commit SHA und Workflow-Referenz. Wenn das Deployment-System oder der Admission-Controller diese Daten nicht gegen eine definierte Policy validiert, kann am Ende trotzdem ein Artefakt aus einem unerwarteten Workflow, aus einem ungehärteten Runner oder aus einem fragwürdigen Zwischenpfad live gehen.
Praktisch heißt das: Die eigentliche Sicherheitsfrage lautet nicht „Haben wir eine Attestierung erzeugt?“, sondern „Darf ohne verifizierte Attestierung überhaupt in eine produktive Stufe deployt werden?“ Erst wenn diese Frage technisch erzwungen wird, bekommt Provenance operativen Wert.
SLSA schafft eine gemeinsame Sprache für Build-Vertrauen
Gerade in größeren Organisationen reden Entwicklung, Plattformbetrieb, Security, Einkauf und Audit oft aneinander vorbei. Die einen sprechen über Runner-Härtung, die anderen über Nachweise, wieder andere über Lieferantenanforderungen. SLSA hilft hier vor allem als gemeinsame Sprache. Das Framework beschreibt schrittweise steigende Absicherungsniveaus für Quellen, Builds und Abhängigkeiten und macht damit diskutierbar, welches Vertrauensniveau ein Release-Prozess tatsächlich erreicht.
Das ist auch deshalb nützlich, weil NIST im SSDF mit PS.3.2 ausdrücklich das Sammeln und Teilen von Provenance-Daten für Software-Releases nennt. Gleichzeitig betont das SSDF, dass sichere Entwicklungspraktiken nicht als starre Checkliste gedacht sind, sondern als risikobasierter Verbesserungsprozess. Genau diese Sicht passt gut zu SLSA: nicht alles sofort perfekt, aber mit klarer Richtung und nachprüfbaren Zwischenstufen.
Für IT-Management bedeutet das einen wichtigen Perspektivwechsel. Statt unpräzise zu fragen, ob die Pipeline „schon sicher genug“ ist, lässt sich konkreter prüfen, ob Build-Schritte isoliert genug laufen, ob die Herkunft eines Artefakts nachvollziehbar ist und ob die Organisation nur Nachweise sammelt oder daraus echte Policy-Entscheidungen ableitet.
Provenance muss Quelle, Workflow und Artefakt belastbar zusammenbinden
Ein Herkunftsnachweis wird erst dann nützlich, wenn er die für den Betrieb relevanten Verknüpfungen wirklich enthält. Dazu gehören mindestens die Quelle, der Commit-Stand, der auslösende Workflow, die Build-Identität und das konkrete Artefakt. Die GitHub-Attestierungsdokumentation nennt genau solche Informationen als Kernbestandteile. in-toto beschreibt dasselbe Prinzip aus Lieferkettenperspektive: transparent machen, welche Schritte von wem und in welcher Reihenfolge durchgeführt wurden.
Der operative Mehrwert liegt darin, dass Incident- und Plattformteams damit nicht mehr nur ein Image-Digest sehen, sondern dessen Entstehungspfad prüfen können. Kam das Artefakt aus dem freigegebenen Repository? Wurde der Build über den erwarteten Workflow angestoßen? Lief er in einer Umgebung, der das Unternehmen vertrauen will? Und entspricht das Ergebnis tatsächlich dem Objekt, das nun in Registry, Paketquelle oder Kubernetes-Cluster auftaucht?
Wo diese Bindung unsauber bleibt, entstehen gefährliche Grauzonen. Dann wird vielleicht dasselbe Deployment-Label mit mehreren Build-Varianten verbunden, ein Hotfix außerhalb des Standard-Workflows eingeschleust oder ein temporärer Runner zur faktischen Produktionsstraße. Provenance ohne präzise Bindung reduziert dieses Risiko nicht, sondern dokumentiert es nur schöner.
Signaturen sind wichtig, aber sie ersetzen keine Policy
Werkzeuge wie Sigstore und Cosign haben die Hürde für Signaturen und Attestierungen erfreulich gesenkt. Das ist ein echter Fortschritt. Vor allem keyless Modelle mit OIDC und transparente Protokollierung helfen, private Schlüsselverwaltung zu entschärfen und Nachweise besser prüfbar zu machen. Trotzdem sollten Teams Signaturen nicht mit Freigabelogik verwechseln.
Eine Signatur beantwortet nicht automatisch, ob der zugrunde liegende Workflow genehmigt war, ob der Build aus einer wiederverwendbaren, gehärteten Pipeline kam oder ob wichtige Prüfungen umgangen wurden. Auch GitHub weist darauf hin, dass Attestierungen keine Garantie für sichere Software sind, sondern belastbare Aussagen über Herkunft und Build-Zusammenhang liefern. Die Risikobewertung bleibt also eine Organisationsaufgabe.
Genau deshalb braucht jede SLSA-Initiative eine klare Policy-Schicht. Welche Signaturquellen werden akzeptiert? Welche OIDC-Identitäten gelten als vertrauenswürdig? Welche Repositories, Branch-Schutzregeln oder Workflow-Pfade müssen in der Provenance erscheinen? Unter welchen Bedingungen darf ein Ausnahmedeployment stattfinden? Ohne diese Antworten bleibt die Technik korrekt implementiert, aber betrieblich untersteuert.
Release-Gates müssen vom Nachweis zur Entscheidung kommen
Der CISA Software Acquisition Guide ist in dieser Hinsicht interessant, weil er Softwareentwicklung, Lieferkette, Deployment und Vulnerability Management ausdrücklich zusammen betrachtet. Genau diese Verbindung fehlt intern oft noch. Teams erzeugen Herkunftsnachweise in der Build-Welt, während Freigaben, Einkaufsvorgaben oder Kubernetes-Policies in anderen Werkzeugen und Verantwortlichkeiten leben.
Reife entsteht erst, wenn Release-Gates diese Welten zusammenziehen. Vor einer produktiven Freigabe sollte maschinell prüfbar sein, ob ein Artefakt aus einem zugelassenen Workflow stammt, ob die erwartete Provenance vorhanden ist, ob Signatur und Digest zusammenpassen und ob gegebenenfalls SBOM oder weitere Attestierungen sauber referenziert sind. Für hochkritische Umgebungen gehört dazu außerdem die Frage, ob nur wiederverwendbare und zentral gepflegte Build-Workflows das erforderliche Vertrauensniveau liefern dürfen.
Das klingt nach zusätzlicher Bremse, ist aber im Gegenteil oft eine Entlastung. Wenn Freigabekriterien sauber codiert sind, müssen Security- oder Plattformteams weniger Einzelfallprüfungen improvisieren. Aus einer nervösen Chat-Nachfrage wird dann eine wiederholbare Regel: Kein Production-Deploy ohne gültige Herkunftskette. Genau so wird aus SLSA ein Betriebsinstrument statt ein Architekturbegriff.
Worauf Plattform- und DevOps-Teams jetzt konkret achten sollten
- Nicht beim Signieren stehen bleiben: Attestierungen müssen vor produktiven Deployments verbindlich verifiziert werden.
- Vertrauenswürdige Build-Pfade definieren: Wiederverwendbare, gehärtete Workflows und Runner sollten bevorzugt oder erzwungen werden.
- Provenance vollständig binden: Repository, Commit, Workflow, Identität und Artefakt-Digest müssen zusammenpassen.
- Policy explizit machen: Akzeptierte Signaturquellen, OIDC-Claims, Ausnahmepfade und Zielumgebungen gehören in prüfbare Regeln.
- Deployment und Einkauf anschließen: Herkunftsnachweise sind nicht nur für Build-Teams relevant, sondern auch für Beschaffung, Audit und Incident Response.
- Nachweise auffindbar halten: Bei Störungen oder Lieferantenfragen muss die Herkunft eines Releases schnell rekonstruierbar sein.
Fazit
SLSA lohnt sich nicht deshalb, weil ein weiteres Framework auf der Checkliste steht. Der Nutzen entsteht dort, wo Unternehmen Herkunftsnachweise, Signaturen und Build-Härtung in echte Freigabeentscheidungen übersetzen. Solange Attestierungen nur produziert, aber nicht an Release-Gates verifiziert werden, bleibt die Lieferkette besser dokumentiert, aber nicht automatisch besser geschützt.
Für DevOps-, Plattform- und Security-Teams ist das die entscheidende Reifegrenze. Nicht der Nachweis an sich, sondern seine Durchsetzung im Alltag macht den Unterschied. Wer Provenance sauber an produktive Deployments koppelt, gewinnt belastbarere Freigaben, schnellere Incident-Analyse und eine deutlich ehrlichere Aussage darüber, welchem Build-Prozess das Unternehmen wirklich vertraut.
