Existenznachweis vs. Sigstore: Brauchst du beides?

Sigstore und Existenznachweis sind eigentlich keine Konkurrenten. Sigstore beantwortet die Frage Wer hat dieses Software-Artefakt signiert, und steht das Signaturereignis in einem öffentlichen Log? Label 309 beantwortet die Frage Haben genau diese Bytes zu einem öffentlichen Zeitpunkt existiert – nachweisbar, ohne einem einzelnen Dienst vertrauen zu müssen? Für die meisten Software-Teams ist die stärkste Kombination, beides einzusetzen: Releases mit Sigstore signieren und protokollieren und anschließend den Release-Nachweis mit Label 309 verankern.

Sigstore ist ein Ökosystem für Software-Signierung und Transparenz. Label 309 verankert Content-Hashes, Manifeste, versiegelte Dateien oder eine Merkle-Wurzel auf Cardano, sodass später jeder verifizieren kann, dass genau diese Daten zu einer bestimmten Blockzeit existiert haben – allein anhand der Transaktion und eines öffentlichen Explorers, ohne einen Herausgeber-Server im Spiel.

Was ist Sigstore?

Sigstore ist ein Open-Source-Ökosystem, das Artefakte der Software-Lieferkette signiert und die Signaturereignisse in einem öffentlichen Log festhält.

Der gängige schlüssellose Workflow nutzt eine OpenID-Connect-Identität (OIDC), ein kurzlebiges, von Fulcio ausgestelltes Zertifikat, eine clientseitig erzeugte Signatur und einen Eintrag im Rekor-Transparenz-Log. Ziel ist es, das Signieren von Artefakten einfacher zu machen und dabei einen prüfbaren öffentlichen Nachweis darüber zu führen, wer was signiert hat.

Sigstore passt besonders gut für:

Container-Images;
Binärdateien und Pakete;
Software-Stücklisten (SBOMs);
Provenienz-Attestierungen;
CI/CD- und Release-Signatur-Workflows;
den Nachweis, dass ein Artefakt von einer erwarteten Identität signiert wurde.

Es ist für das Vertrauen in die Software-Lieferkette gebaut.

Was ist Label 309?

Label 309 ist ein offener, anbieterneutraler Standard für Existenznachweis-Einträge auf Cardano. Der Vorschlag wurde im Cardano-CIP-Prozess eingereicht und wird derzeit von den CIP-Editoren geprüft; die On-Chain-Kennung ist das Metadaten-Label 309.

Ein Label-309-Eintrag kann sich auf einen oder mehrere Content-Hashes, eine Merkle-Wurzel über viele Dateien, optionale Signaturen auf Eintragsebene, versiegelte Inhalte für Empfängerschlüssel und inhaltsadressierte Speicher-URIs festlegen. Der eigentliche Nachweis ist eigenständig anhand der Cardano-Transaktion und der geprüften Bytes verifizierbar – ohne Konto, ohne Login und ohne Abhängigkeit von einem einzelnen Anbieter.

Für Software-Teams macht ihn das nützlich, um den Release-Nachweis zu verankern:

Artefakt-Digests;
Sigstore-Bundles;
SLSA-Provenienz und in-toto-Statements;
SBOMs;
Release-Manifeste;
Build-Logs und Testergebnisse;
Vorfall-Beweise.

Es ist eine öffentliche, mit Zeitstempel versehene Commitment-Schicht.

Was ist der eigentliche Unterschied?

Sigstore beantwortet Fragen zu Identität und Signierung von Software. Label 309 beantwortet Fragen zu Existenz und Zeitpunkt beliebiger Bytes.

Sigstore hilft, diese Fragen zu beantworten:

Wurde dieses Container-Image signiert?
Welche OIDC-Identität war an das Signatur-Zertifikat gebunden?
Wurde das Signaturereignis im Transparenz-Log festgehalten?
Lässt sich die Artefakt-Signatur verifizieren?
Entspricht das meiner Richtlinie für vertrauenswürdige Signierende?

Label 309 hilft, diese Fragen zu beantworten:

Hat dieser Artefakt-Digest bis zu dieser Cardano-Blockzeit existiert?
War diese SBOM Teil des festgeschriebenen Release-Nachweises?
Existierte dieses Release-Manifest vor einem Vorfall?
Hat eine bekannte Projekt-Identität den Eintrag signiert (optional)?
Kann ein Empfänger ein versiegeltes Beweis-Bundle später entschlüsseln?

Diese beiden Fragenkomplexe ergänzen sich, statt sich zu überschneiden.

Macht Rekor das nicht schon?

Wenn du Sigstore nutzt, nutze Rekor – es ist das richtige Werkzeug für seine Aufgabe.

Rekor ist ein Transparenz-Log für Signaturen und Software-Metadaten, gebaut, um Signaturereignisse auffindbar und prüfbar zu machen. Die Dokumentation von Sigstore beschreibt es als nur-anfügendes, manipulationsresistentes Ledger, das Prüfer auf Konsistenz überwachen können – mit dem Designziel, dass jeder Versuch, einen Eintrag zu verändern oder zu entfernen, erkennbar ist statt unbemerkt.

Label 309 ersetzt Rekor nicht. Es liefert eine andere Art von Anker:

einen öffentlichen Zeitstempel, der im Cardano-Konsens verwurzelt ist statt in einem von einem Dienst betriebenen Log;
ein definiertes Eintragsschema unter dem Metadaten-Label 309;
die optionale versiegelte Aufbewahrung sensibler Beweise;
die Zustellung an bestimmte Empfänger;
Merkle-Bündelung für große Beweismengen;
eine Verifizierung, die nicht davon abhängt, dass ein bestimmter Anbieter online bleibt.

Wenn ein Release bereits Sigstore-Beweise hat, verankere diese Beweise. Wirf sie nicht weg.

Wie sähe ein kombinierter Workflow aus?

Eine CI/CD-Pipeline kann einen Release-Nachweis-Ordner zusammenstellen und ihn dann festschreiben.

Dieser Ordner könnte das Release-Manifest, Artefakt-Digests, Cosign-Signaturen oder -Bundles, Rekor-Eintragsreferenzen, SLSA-Provenienz, in-toto-Attestierungen, SBOMs, Build-Logs, Testberichte und Deployment-Manifeste enthalten.

Die Pipeline hasht jede Datei, baut einen Merkle-Baum und veröffentlicht einen einzigen Label-309-Eintrag, der die Merkle-Wurzel trägt. Weil die Wurzel ein einziger 32 Byte großer Wert ist, kann eine einzige Transaktion für eine beliebig große Beweismenge einstehen; ein Inklusionsnachweis zeigt später, dass eine bestimmte Datei Teil dieser Wurzel war. Der Eintrag kann außerdem eine optionale Signatur einer Projekt- oder Unternehmensidentität tragen. Zur Mechanik, wie man viele Dateien in eine einzige Wurzel faltet, siehe Ein Eintrag für Tausende Dateien; für das durchgängige Pipeline-Muster siehe CI/CD-Build-Nachweise verankern.

Später verifiziert ein Prüfer zwei unabhängige Dinge:

Sigstore – wer was signiert hat, unter welcher Identität und in welchem Transparenz-Log-Kontext;
Label 309 – welche Beweismenge zu einer öffentlichen Cardano-Zeit existiert hat.

Verifiziert Label 309 die Software-Signatur?

Nein. Label 309 weiß nicht, ob eine Cosign-Signatur gültig ist, ob eine OIDC-Identität vertrauenswürdig ist, ob eine Richtlinie erfüllt ist oder ob ein Build die SLSA-Erwartungen erfüllt.

Was es beweisen kann, ist, dass die Signaturdatei, das Bundle, die Attestierung, die SBOM oder das Release-Manifest zu einem öffentlichen Zeitpunkt existiert hat. Die Werkzeuge der Software-Lieferkette verifizieren ihre eigenen Formate weiterhin nach ihren eigenen Regeln.

Diese Trennung ist gesund. Ein Existenznachweis sollte nicht vorgeben, eine Richtlinien-Engine für Software-Signierung zu sein.

Bewahrt Sigstore deine gesamte Beweismenge auf?

Nicht von allein. Sigstore konzentriert sich auf Signierung und Transparenz für Software-Artefakte. Ein echter Release-Prozess muss oft auch Build-Logs, SBOMs, Testberichte, Deployment-Manifeste, Vorfall-Zeitleisten und private Beweis-Bundles aufbewahren.

Label 309 kann all diese Materialien als eine Menge festschreiben. Sind einige Materialien sensibel, können sie privat bleiben und über eine Merkle-Wurzel festgeschrieben werden, ohne die Inhalte zu veröffentlichen – oder versiegelt werden, sodass der Chiffretext in einem inhaltsadressierten Speicher liegt und nur ein Schlüsselinhaber ihn entschlüsseln kann. Ein versiegelter Eintrag hält den Klartext nur für die vorgesehenen Empfänger lesbar; er garantiert für sich genommen keine Anonymität, und ein Empfänger kann den Klartext nach dem Entschlüsseln immer noch weitergeben.

Das macht Label 309 nützlich für Audit, Vorfallreaktion, Beschaffung, Sicherheitsprüfungen durch Kunden und langfristige Release-Nachweise.

Wann solltest du Sigstore nutzen?

Nutze Sigstore, wenn du Software-Artefakte signieren und identitätsgestützt verifizieren musst. Es ist die richtige Wahl zum Signieren von Container-Images, Binärdateien und Paketen; für öffentliche Open-Source-Release-Workflows; für schlüsselloses Signieren mit OIDC-Identitäten; für Transparenz in der Lieferkette; für Verifizierungsrichtlinien auf Basis erwarteter Signierender; und für die Integration in vorhandene Distributions-Werkzeuge.

Sigstore ist eine starke Standardwahl für modernes Software-Signieren.

Wann solltest du Label 309 nutzen?

Nutze Label 309, wenn du ein öffentliches, mit Zeitstempel versehenes Commitment um den Beweis herum brauchst – um Release-Manifeste zu verankern, zu beweisen, dass eine SBOM vor einer Schwachstellen-Offenlegung existiert hat, eine Merkle-Wurzel über eine Release-Beweismenge festzuschreiben, versiegelte Vorfall-Materialien aufzubewahren, eine an Kunden gelieferte Artefaktmenge zu beweisen oder einen Nachweis vorzuhalten, der nicht davon abhängt, dass ein CI-Anbieter oder ein Artefakt-Registry-Dashboard online bleibt.

Label 309 ersetzt das Signieren nicht. Es ist ein Zeitanker und ein Beweis-Commitment-Format. Die quelloffene cardanowall CLI ist genau für diese Art von Automatisierung gebaut: gateway-unabhängig und raw-seed-first, sodass sie sich in eine Pipeline einfügt, ohne dass eine Website im Spiel ist. Den vollständigen Ablauf zeigt Die CLI in der Automatisierung nutzen.

Was beweist keines der beiden Systeme?

Keines der beiden Systeme beweist, dass die Software sicher ist.

Ein signiertes Artefakt kann trotzdem eine Schwachstelle enthalten. Eine SBOM mit Zeitstempel kann unvollständig sein. Ein Build-Log kann eine fehlkonfigurierte Pipeline dokumentieren. Ein Release kann gut dokumentiert und trotzdem unsicher sein.

Sigstore und Label 309 helfen, Integrität, Identität, Transparenz, Zeitpunkt und Beweiskontinuität zu beweisen. Die Sicherheit selbst hängt weiterhin von Code-Review, Build-Isolation, Abhängigkeitsverwaltung, Tests, Schwachstellenreaktion und betrieblichen Kontrollen ab. Zu den allgemeinen Grenzen dessen, was ein Nachweis belegen kann und was nicht, siehe Was ein Nachweis nicht beweist.

Die Kurzfassung

Nutze Sigstore, um Software zu signieren und Signaturereignisse transparent zu machen. Nutze Label 309, um den Release-Nachweis – Manifeste, Logs und Attestierungen – an einer öffentlichen Cardano-Zeit zu verankern, die kein Anbieter heimlich verschieben kann. Zusammen machen sie die Software-Geschichte später weitaus leichter verifizierbar.

Weiterführende Lektüre

CI/CD-Build-Nachweise verankern – das vollständige Pipeline-Muster zum Hashen, Bündeln und Veröffentlichen von Build-Nachweisen.
Ein Eintrag für Tausende Dateien – wie eine einzige Merkle-Wurzel sich auf eine beliebig große Beweismenge festlegt.
Die CLI in der Automatisierung nutzen – Veröffentlichen und Verifizieren aus einer Pipeline heraus mit der cardanowall CLI.
Was ein Nachweis nicht beweist – die ehrlichen Grenzen eines Existenznachweises.
Sigstore und seine Dokumentation – schlüsselloses Signieren, Fulcio-Zertifikate und das Rekor-Transparenz-Log.