Wie verankerst du CI/CD-Build-Nachweise an einem öffentlichen Zeitstempel?

Ja – eine CI/CD-Pipeline kann nachweisen, was sie wann gebaut hat. Das Muster ist einfach: Hash die Ausgaben, die zählen (Artefakte, SBOMs, Logs, Release-Manifeste), falte diese Hashes zu einer Merkle-Wurzel und veröffentliche einen einzelnen Label 309-Eintrag für den Build, das Release oder das Zeitfenster. Später kann jeder beweisen, dass ein bestimmtes Artefakt oder Manifest Teil dieses festgeschriebenen Bündels war und dass das Bündel zu oder vor einer öffentlichen Blockzeit existierte.

Das ersetzt weder SLSA, Sigstore, GitHub Artifact Attestations noch in-toto. Es ergänzt sie um genau eine Sache, die keines davon direkt liefert: einen unabhängigen, öffentlichen, herausgeberunabhängigen Zeitanker, den kein Anbieter kontrolliert.

Was sollte eine CI/CD-Pipeline tatsächlich nachweisen?

Beginne mit den Nachweisen, die du vielleicht in einem Jahr vorlegen musst.

Ein CI/CD-Nachweis kann sich auf Folgendes festlegen:

Release-Artefakte;
Container-Image-Digests;
SBOM-Dateien (Software Bill of Materials);
SLSA-Provenienz-Attestierungen;
in-toto-Link-Metadaten;
Build-Logs;
Testberichte;
Deployment-Manifeste;
Changelog-Snapshots;
Quellcode-Commit-Referenzen;
Dependency-Lockfiles;
signierte Prüfsummen;
Release Notes.

Hash nicht alles, nur weil es existiert. Hash die Artefakte, die für Sicherheit, Audit, Incident Response, Kundenvertrauen oder Release-Integrität wichtig sind.

Ein guter Nachweis beantwortet eine konkrete zukünftige Frage: „War genau dieses Artefakt oder Manifest Teil der Release-Nachweise, die wir damals festgeschrieben haben?“

Wie funktioniert das Muster der Merkle-Bündelung?

Für ein einzelnes Artefakt reicht ein einziger Hash-Nachweis.

Für ein Release hast du meist viele Artefakte, und jedes davon als eigene Transaktion zu veröffentlichen, ist Verschwendung. Eine Merkle-Wurzel löst das. Du hashst jeden Nachweis-Eintrag zu einem Blatt, faltest die geordneten Blätter zu einer einzelnen 32 Byte großen Wurzel und veröffentlichst nur die Wurzel – ein einziger on-chain Eintrag, der das gesamte Release abdeckt.

Die Pipeline:

Baut die Artefakte.
Erzeugt oder sammelt SBOMs, Attestierungen, Logs und Manifeste.
Hasht jeden Nachweis-Eintrag zu einem Blatt.
Stellt eine geordnete Blattliste zusammen.
Baut den Merkle-Baum und berechnet die Wurzel.
Veröffentlicht einen Label-309-Eintrag mit der Wurzel.
Speichert die Blattliste und die Inklusionsnachweise zusammen mit den Release-Nachweisen.

Später nimmt ein Verifizierer eine Datei oder einen Digest, prüft ihren Inklusionsnachweis und bestätigt, dass der Eintrag zur Wurzel im Label-309-Eintrag gehört. Der Inklusionsnachweis wächst nur mit dem Logarithmus der Bündelgröße, sodass eine Wurzel über Tausende von Blättern noch in Millisekunden verifiziert – vollständig offline, ohne Gateway und ohne Netzwerk. Die vollständige Mechanik findest du unter ein Eintrag für Tausende von Dateien.

Warum nicht einfach auf vorhandene Attestierungen verlassen?

Nutze vorhandene Attestierungen – und verankere sie dann.

SLSA-Provenienz beschreibt, wo, wann und wie ein Software-Artefakt erzeugt wurde. GitHub Artifact Attestations belegen die Build-Provenienz für Artefakte wie Binaries und Container-Images. Sigstore zeichnet signierte Supply-Chain-Metadaten in einem öffentlichen, nur-anfügenden Transparenz-Log namens Rekor auf. in-toto ist ein Framework, um zu verifizieren, dass jeder Schritt in einer Lieferkette wie geplant, von der richtigen Partei und auf den richtigen Eingaben ausgeführt wurde.

Jedes davon löst ein echtes Problem. Label 309 löst ein anderes: einen Cardano-verankerten, unabhängig verifizierbaren Nachweis zu veröffentlichen, dass ein bestimmter Nachweissatz zu einer bestimmten öffentlichen Zeit existierte. Eine starke Pipeline entscheidet sich nicht zwischen „Attestierungen oder Existenznachweis“. Sie nutzt beides:

SLSA- oder GitHub-Attestierungen für die Build-Provenienz;
Sigstore für Signier- und Transparenz-Log-Workflows;
in-toto für die Verifizierung von Lieferketten-Schritten;
Label 309 für einen öffentlichen Zeitanker über den gesamten Nachweissatz.

Was fügt Label 309 obendrauf hinzu?

Es fügt ein dauerhaftes öffentliches Commitment auf Cardano hinzu.

Dieses Commitment kann ein einzelnes Release-Manifest abdecken oder eine Merkle-Wurzel über viele Nachweis-Einträge. Es kann von einer Projekt- oder Unternehmensidentität signiert werden. Und es lässt sich allein mit den Transaktions-Metadaten und einem öffentlichen Cardano-Explorer verifizieren – ohne Konto, ohne Login und ohne darauf angewiesen zu sein, dass das Dashboard des ursprünglichen CI-Anbieters online bleibt.

Diese Unabhängigkeit zählt am meisten, wenn ein Team beweisen muss, dass die Nachweise vor einem späteren Ereignis existierten:

einer Schwachstellen-Offenlegung;
einem Sicherheitsvorfall;
einer Sicherheitsprüfung durch einen Kunden;
einem Beschaffungs-Audit;
einer Compliance-Frist;
einem Release-Streit;
einer Lieferketten-Untersuchung.

Der Nachweis gibt der Zeitachse einen Anker, den niemand der Beteiligten heimlich verschieben kann.

Was würde ein Prüfer verifizieren?

Ein Prüfer sollte die Kette von einem einzelnen Artefakt zurück zum on-chain Eintrag verfolgen können:

Nimm das geprüfte Artefakt oder die SBOM.
Berechne dessen Hash.
Prüfe den Inklusionsnachweis gegen die Merkle-Wurzel des Releases.
Bestätige, dass die Wurzel in einem Label-309-Eintrag erscheint.
Schlage die Cardano-Transaktion nach und lies ihre Blockzeit.
Verifiziere eine etwaige Eintragssignatur.
Prüfe die umgebende Provenienz oder Attestierung nach ihren eigenen Regeln.

Das trennt zwei Fragen sauber. Der Label-309-Nachweis beantwortet: Wurde dieser Nachweis zu dieser öffentlichen Zeit festgeschrieben? Die SLSA-, Sigstore-, GitHub- oder in-toto-Ebene beantwortet: Was sagt dieser Nachweis darüber aus, wie das Artefakt gebaut, signiert oder verteilt wurde? Keine versucht, die Aufgabe der anderen zu übernehmen.

Was gehört in das Release-Manifest?

Ein Release-Manifest sollte langweilig und vollständig sein. Es könnte enthalten:

Release-Name und -Version;
Repository-URL;
Quellcode-Commit;
Build-Workflow-Kennung;
Build-Aufruf-ID;
Artefaktnamen und -digests;
Container-Image-Digests;
SBOM-Datei-Digests;
Attestierungs-Datei-Digests;
Testbericht-Digests;
Build-Log-Digest;
den vom CI-System gemeldeten Zeitstempel;
die Label-309-Transaktionsreferenz, nach dem Veröffentlichen hinzugefügt.

Das Manifest selbst kann gehasht und als Blatt aufgenommen werden. Es dient zugleich als menschenlesbarer Index, der jedes andere Blatt im Bündel erklärt. Halte das Format stabil: Ein Nachweis ist leichter zu verifizieren, wenn die Nachweisstruktur von einem Release zum nächsten vorhersehbar ist.

Sollte die Pipeline den Eintrag signieren?

Meistens ja.

Eine Merkle-Wurzel beweist, dass eine Liste festgeschrieben wurde. Eine Signatur zeigt zusätzlich, dass ein Projekt, ein Unternehmen, ein Release-System oder eine freigegebene Identität für dieses Commitment einsteht. In Label 309 ist das eine optionale Signatur auf Eintragsebene – Urheberschaft ist für die Verifizierung der Existenzbehauptung nie erforderlich, steht aber zur Verfügung, wenn du Nachvollziehbarkeit willst.

Verwalte den Signaturschlüssel bewusst. Verstreue keine langlebigen Identity Seeds über beliebige CI-Runner. Je nach Bedrohungsmodell nutze eine dedizierte Release-Identität, einen kontrollierten Signaturdienst, einen hardwaregestützten Workflow oder einen selbst gehosteten Runner mit strengen Zugriffskontrollen. Die quelloffene cardanowall CLI ist genau dafür gebaut – gateway-unabhängig und raw-seed-first, sodass sie sich in Automatisierung einfügt, ohne dass eine Website dazwischen sitzt. Den durchgängigen Ablauf findest du unter die CLI in der Automatisierung nutzen.

Eine Signatur fügt Nachvollziehbarkeit hinzu. Sie macht eine schwache Build-Pipeline nicht von selbst sicher.

Wo sollte die Blattliste liegen?

Speichere sie zusammen mit den Release-Nachweisen.

Die Blattliste und die Inklusionsnachweise sind das, was dir erlaubt, einzelne Einträge später zu beweisen. Wenn du nur die Wurzel veröffentlichst und dann die Blattliste verlierst, kannst du immer noch beweisen, dass irgendeine Liste existierte – aber du kannst womöglich nicht mehr beweisen, dass ein bestimmtes Artefakt darin enthalten war.

Gute Speicheroptionen hängen vom Workflow ab:

häng sie ans Release-Archiv an;
leg sie in einem Artefakt-Repository ab;
bewahre sie in einem internen Nachweis-Bucket auf;
versiegle sie als verschlüsselten Inhalt für vertrauliche Nachweise;
veröffentliche sie über inhaltsadressierten Speicher, wenn es sicher ist, sie öffentlich zu machen.

Die Wurzel ist der Anker. Die Blattliste ist die Karte.

Wie oft sollte eine Pipeline veröffentlichen?

Passe den Nachweistakt an den Release-Takt an. Gängige Optionen:

ein Nachweis pro Release;
ein Nachweis pro Build;
ein Nachweis pro Deployment;
ein Nachweis pro Tag für fortlaufende Logs;
ein Nachweis pro sicherheitsrelevantem Ereignis.

Zu selten zu veröffentlichen schwächt die Zeitachse; zu oft zu veröffentlichen verursacht Kosten und operatives Rauschen. Die Merkle-Bündelung lässt dich einen Takt wählen, der zur geschäftlichen Frage passt. Wenn ein Kunde fragt „Was genau wurde in Version 2.3.1 ausgeliefert?“, reicht ein Nachweis pro Release völlig. Wenn eine Aufsichtsbehörde oder ein Prüfer fragt, ob das Monitoring kontinuierlich war, dienen tägliche oder stündliche Commitments besser.

Veröffentlichen kostet Geld, weil das Gateway echte Cardano-Transaktionsgebühren plus Speicher bezahlt – der Takt ist also ein echter Kompromiss zwischen Kosten und Nachweis, kein kostenloser Regler.

Was beweist ein CI/CD-Nachweis nicht?

Er beweist nicht, dass der Build sicher war.

Ein Existenznachweis kann zeigen, dass ein Artefakt, eine SBOM, ein Log oder ein Manifest zu einer öffentlichen Zeit existierte; dass der Eintrag in einem festgeschriebenen Bündel enthalten war; und dass ein Schlüssel den Eintrag signiert hat. Das ist alles, was er bescheinigt.

Er beweist nicht, dass der Quellcode sicher war. Er beweist nicht, dass der Runner nicht kompromittiert war. Er beweist nicht, dass die Dependencies frei von Schwachstellen waren. Er beweist nicht, dass die SBOM vollständig ist. Und er beweist nicht, dass eine Attestierung vertrauenswürdig ist, es sei denn, die eigenen Verifizierungsregeln dieser Attestierung gehen auf. Genau deshalb steht Label 309 neben Supply-Chain-Sicherheitswerkzeugen und ersetzt sie nicht – die allgemeinen Grenzen findest du unter was ein Nachweis nicht beweist.

Was ist eine gute erste Umsetzung?

Beginne mit einem Release-Nachweis. Für jedes Release:

Erzeuge deine üblichen Artefakte.
Erzeuge oder sammle SBOMs und Attestierungen.
Erstelle ein Release-Manifest.
Hash jede Nachweisdatei zu einem Blatt.
Baue die Merkle-Wurzel.
Veröffentliche einen signierten Label-309-Eintrag.
Speichere die Transaktionsreferenz in den Release Notes.
Lege das Manifest, die Blattliste und die Inklusionsnachweise zusammen mit dem Release ab.

Das gibt dir eine praktische Nachweiskette, ohne dein Build-System gleich am ersten Tag umzubauen. Von dort aus erweiterst du auf tägliche Logs, Deployment-Manifeste oder Automatisierung mit höherem Volumen.

Die Kurzfassung

Ein CI/CD-Nachweis ist ein mit Zeitstempel versehenes Commitment auf Release-Nachweise.

Hash die Artefakte, SBOMs, Logs, Attestierungen und Manifeste, die zählen. Bündle sie zu einer Merkle-Wurzel. Veröffentliche diese Wurzel in einem Label-309-Eintrag. Signiere den Eintrag, wenn eine Projekt- oder Unternehmensidentität dafür einstehen soll.

Behalte SLSA, Sigstore, GitHub Artifact Attestations und in-toto für Provenienz und Supply-Chain-Metadaten. Füge Label 309 als den unabhängigen öffentlichen Zeitanker hinzu, der den gesamten Nachweissatz an einen Moment bindet, den kein Anbieter verschieben kann.

Weiterführende Lektüre

Ein Eintrag für Tausende von Dateien – wie die Merkle-Bündelung einen ganzen Satz unter einer einzigen Wurzel verankert.
Die CLI in der Automatisierung nutzen – Veröffentlichen und Verifizieren aus einer Pipeline heraus steuern.
Existenznachweis vs. Sigstore – wie sich die beiden Ebenen unterscheiden und wo sie zusammenpassen.
SLSA-Build-Provenienz – die SLSA-Provenienz-Spezifikation.
Sigstore und das Rekor-Transparenz-Log – schlüsselloses Signieren mit einem öffentlichen, nur-anfügenden Log.
GitHub Artifact Attestations – Build-Provenienz für auf GitHub gebaute Artefakte.
in-toto – das Framework für die Integrität der Software-Lieferkette.