Proof of Existence vs Sigstore: do you need both?

Sigstore and Proof of Existence are not really competitors. Sigstore answers who signed this software artifact, and is the signing event in a public log? Label 309 answers did these exact bytes exist by a public time, provable without trusting any one service? For most software teams the strongest setup uses both: sign and log releases with Sigstore, then anchor the release evidence with Label 309.

Sigstore is a software-signing and transparency ecosystem. Label 309 anchors content hashes, manifests, sealed files, or a Merkle root on Cardano so anyone can later verify that exact data existed by a specific block time — using only the transaction and a public explorer, with no issuer server in the loop.

What is Sigstore?

Sigstore is an open-source ecosystem for signing software supply-chain artifacts and recording the signing events in a public log.

Its common keyless workflow uses an OpenID Connect (OIDC) identity, a short-lived certificate issued by Fulcio, a signature created on the client, and an entry in the Rekor transparency log. The point is to make signing artifacts easier while keeping an auditable public record of who signed what.

Sigstore is a strong fit for:

container images;
binaries and packages;
software bills of materials (SBOMs);
provenance attestations;
CI/CD and release-signing workflows;
verifying that an artifact was signed by an expected identity.

It is built for software supply-chain trust.

What is Label 309?

Label 309 is an open, vendor-neutral standard for Proof of Existence records on Cardano. The proposal has been submitted to the Cardano CIP process and is under review by the CIP editors; the on-chain identifier is metadata label 309.

A Label 309 record can commit to one or more content hashes, a Merkle root over many files, optional record-level signatures, sealed payloads addressed to recipient keys, and content-addressed storage URIs. The core proof is independently verifiable from the Cardano transaction and the bytes being checked — no account, no login, and no dependence on any single provider.

For software teams, that makes it useful for anchoring release evidence:

artifact digests;
Sigstore bundles;
SLSA provenance and in-toto statements;
SBOMs;
release manifests;
build logs and test results;
incident evidence.

It is a public, timestamped commitment layer.

What is the actual difference?

Sigstore answers identity and signing questions for software. Label 309 answers existence and timing questions for any bytes.

Sigstore can help answer:

Was this container image signed?
Which OIDC identity was bound to the signing certificate?
Was the signing event recorded in the transparency log?
Can the artifact signature be verified?
Does this match my policy for trusted signers?

Label 309 can help answer:

Did this artifact digest exist by this Cardano block time?
Was this SBOM part of the committed release evidence?
Did this release manifest exist before an incident?
Did a known project identity sign the record (optionally)?
Can a recipient decrypt a sealed evidence bundle later?

Those two sets of questions fit together rather than overlap.

Doesn't Rekor already do this?

If you are using Sigstore, use Rekor — it is the right tool for its job.

Rekor is a transparency log for signatures and software metadata, designed to make signing events discoverable and auditable. Sigstore's documentation describes it as an append-only, tamper-resistant ledger that auditors can monitor for consistency — the design goal being that any attempt to mutate or remove an entry is detectable rather than silent.

Label 309 does not replace Rekor. It provides a different kind of anchor:

a public timestamp rooted in Cardano consensus rather than a service-operated log;
a defined record schema under metadata label 309;
optional sealed preservation of sensitive evidence;
delivery to specific recipients;
Merkle batching for large evidence sets;
verification that depends on no specific provider staying online.

If a release already has Sigstore evidence, anchor that evidence. Do not throw it away.

What would a combined workflow look like?

A CI/CD pipeline can assemble a release-evidence folder, then commit it.

That folder might contain the release manifest, artifact digests, Cosign signatures or bundles, Rekor entry references, SLSA provenance, in-toto attestations, SBOMs, build logs, test reports, and deployment manifests.

The pipeline hashes each file, builds a Merkle tree, and publishes one Label 309 record carrying the Merkle root. Because the root is a single 32-byte value, one transaction can stand in for an arbitrarily large evidence set; an inclusion proof later shows that any specific file was part of that root. The record can also carry an optional signature from a project or company identity. For the mechanics of folding many files into one root, see one record for thousands of files; for the end-to-end pipeline pattern, see anchoring CI/CD build evidence.

Later, an auditor verifies two independent things:

Sigstore — who signed what, under which identity and transparency-log context;
Label 309 — what evidence set existed by a public Cardano time.

Does Label 309 verify the software signature?

No. Label 309 does not know whether a Cosign signature is valid, whether an OIDC identity is trusted, whether a policy is satisfied, or whether a build meets SLSA expectations.

What it can prove is that the signature file, bundle, attestation, SBOM, or release manifest existed by a public time. The software supply-chain tools still verify their own formats under their own rules.

That separation is healthy. A Proof of Existence should not pretend to be a software-signing policy engine.

Does Sigstore preserve your whole evidence set?

Not by itself. Sigstore focuses on signing and transparency for software artifacts. A real release process often also needs to preserve build logs, SBOMs, test reports, deployment manifests, incident timelines, and private evidence bundles.

Label 309 can commit those materials as one set. If some materials are sensitive, they can stay private and be committed through a Merkle root without publishing the contents — or sealed so the ciphertext lives in content-addressed storage and only a key holder can decrypt it. A sealed record keeps the plaintext readable only to the intended recipients; it does not, on its own, guarantee anonymity, and a recipient can still leak the plaintext after decrypting.

That makes Label 309 useful for audit, incident response, procurement, customer security reviews, and long-term release evidence.

When should you use Sigstore?

Use Sigstore when you need software-artifact signing and identity-backed verification. It is the right fit for signing container images, binaries, and packages; public open-source release workflows; keyless signing with OIDC identities; supply-chain transparency; verification policies based on expected signers; and integration with existing distribution tooling.

Sigstore is a strong default for modern software signing.

When should you use Label 309?

Use Label 309 when you need a public, timestamped commitment around the evidence — anchoring release manifests, proving an SBOM existed before a vulnerability disclosure, committing a Merkle root over a release evidence set, preserving sealed incident materials, proving a customer-delivered artifact set, or keeping a proof that does not depend on a CI provider or artifact-registry dashboard staying online.

Label 309 is not a replacement for signing. It is a time anchor and an evidence-commitment format. The open-source cardanowall CLI is built for exactly this kind of automation: gateway-agnostic and raw-seed-first, so it fits into a pipeline without a website in the loop. See using the CLI in automation for the full flow.

What does neither system prove?

Neither system proves that the software is secure.

A signed artifact can still contain a vulnerability. A timestamped SBOM can be incomplete. A build log can document a pipeline that was misconfigured. A release can be well-documented and still unsafe.

Sigstore and Label 309 help prove integrity, identity, transparency, timing, and evidence continuity. Security itself still depends on source review, build isolation, dependency management, testing, vulnerability response, and operational controls. For the general limits of what a proof can and cannot establish, see what a proof does not prove.

The short version

Use Sigstore to sign software and make signing events transparent. Use Label 309 to anchor the release evidence — manifests, logs, and attestations — to a public Cardano time that no vendor can quietly move. Together, they make the software story far easier to verify later.