Dein Blog zum Thema digitales Business

Ein fertiges Build-Artefakt sieht immer gleich aus: eine Datei, ein Container-Image, ein Paket. Was man ihm nicht ansieht, ist die Frage, die im Ernstfall zählt. Aus welchem Commit ist es entstanden, welche Pipeline hat es gebaut, mit welchen Abhängigkeiten. Provenance und Attestation beantworten genau das. Sie machen die Herkunft eines Artefakts nachvollziehbar und beweisbar, statt sie zu vermuten.

Was Provenance bedeutet

Provenance ist die dokumentierte Entstehungsgeschichte eines Artefakts. Sie hält fest, welcher Quellcode zugrunde lag, welcher Build-Prozess lief, welche Parameter gesetzt waren und welche Eingaben verarbeitet wurden. Anders als ein simpler Hash, der nur sagt „diese Datei ist unverändert“, sagt Provenance „diese Datei stammt aus diesem Commit, gebaut von dieser Pipeline, zu diesem Zeitpunkt“.

Der Nutzen wird konkret, sobald etwas schiefgeht. Ein kompromittiertes Paket taucht in der Lieferkette auf, eine CVE betrifft eine bestimmte Version, ein Kunde fragt nach der Zusammensetzung einer Auslieferung. Ohne Provenance beginnt dann Rekonstruktionsarbeit aus Logs und Erinnerung. Mit Provenance liegt die Antwort als Datensatz vor.

Attestation: der signierte Beweis

Provenance allein ist eine Behauptung. Attestation macht daraus einen Beweis. Eine Attestation ist eine signierte Aussage über ein Artefakt, ausgestellt von einer Instanz, der man vertraut, in der Regel die Build-Umgebung selbst. Sie bindet die Provenance-Daten kryptografisch an das Artefakt, sodass eine nachträgliche Manipulation auffällt.

In der Praxis erzeugt die Pipeline beim Build eine Attestation, signiert sie und legt sie neben dem Artefakt ab oder in einer Transparenz-Log-Struktur. Wer das Artefakt später einsetzt, kann die Signatur prüfen und die Aussage verifizieren, bevor er es in Produktion lässt. Werkzeuge wie Sigstore mit cosign und in-toto haben diesen Ablauf standardisiert und weitgehend automatisiert.

Wo SLSA ins Spiel kommt

Das SLSA-Framework definiert Stufen für die Integrität der Lieferkette, und Provenance ist darin ein zentraler Baustein. Ab SLSA-Level 1 wird Provenance erwartet, ab Level 2 muss sie von der Build-Plattform signiert sein, ab Level 3 kommen härtere Anforderungen an die Isolation der Build-Umgebung dazu. Wer Provenance und Attestation sauber umsetzt, arbeitet damit automatisch auf ein prüfbares SLSA-Niveau hin.

Wie man es praktisch einführt

Der Einstieg ist kleiner als er klingt. GitHub Actions kann über den Attestation-Mechanismus für Build-Artefakte automatisch signierte Provenance erzeugen, ohne dass man Schlüssel selbst verwaltet. Bei Container-Images übernimmt cosign das Signieren und Attestieren mit wenigen Zeilen im Workflow. Der entscheidende Schritt ist nicht die Erzeugung, sondern die Verifikation: die Provenance muss beim Deployment geprüft werden, sonst bleibt sie ein Datensatz ohne Wirkung.

Ein realistischer erster Meilenstein sieht so aus: jede Auslieferung trägt eine signierte Attestation, die Commit-Hash, Builder-Identität und Zeitpunkt festhält, und das Deployment lehnt Artefakte ohne gültige Attestation ab. Das ist keine große Umstellung an einer bestehenden Pipeline, sondern ein Zusatz an zwei Stellen: beim Bauen und beim Ausrollen.

Warum das kein Papiertiger ist

Provenance und Attestation lösen ein Problem, das die meisten Teams erst bemerken, wenn es akut wird. Sie schließen die Lücke zwischen „wir glauben, das Artefakt kommt aus unserem Repo“ und „wir können es beweisen“. Für Software, die andere Unternehmen einsetzen oder die einer Prüfung standhalten muss, ist dieser Unterschied nicht kosmetisch. Er entscheidet, ob man im Zweifel eine Antwort hat oder eine Suche startet.

Sie wollen wissen, was Ihre Pipeline über die Herkunft ihrer Artefakte tatsächlich beweisen kann? Der GitSecOps QuickCheck prüft Ihre CI/CD-Strecke in drei Werktagen und zeigt konkret, wo Provenance, Signierung und Freigaben stehen. 1.990 Euro netto, Ergebnis in drei Werktagen. Kontakt: mm@crank.zone