Skip to content

SYSTEM Cited by 1 source

Sigstore

Sigstore is an open-source, CNCF-hosted software-signing ecosystem built around three components:

  • Fulcio — a certificate authority that issues short-lived (≈10-minute) code-signing certificates bound to OIDC identities, removing the need for developers to manage long-lived signing keys (keyless signing).
  • Rekor — a public append-only transparency log that records signatures and their associated certificates; signatures that aren't logged in Rekor can't be verified under Sigstore's strictest trust policy.
  • Cosign — a CLI and library for signing and verifying artifacts (container images, blobs, attestations, software bill-of-materials). Language SDKs exist for Go, Rust, Python, JS, Ruby, and others.

The Sigstore bundle format is the serialisation that ships the certificate chain, signature, payload digest, and Rekor inclusion-proof in one portable file, enabling offline verification.

(Sigstore project reference: docs.sigstore.dev.)

Why Sigstore matters for supply chains

Before Sigstore, artifact signing required each publisher to manage long-lived signing keys — operationally costly, risky if a key leaked, and hard to rotate. Consumers had to maintain per-publisher trust-root lists. The practical result was that most open-source artifacts shipped unsigned, and those that were signed used detached PGP files that most consumers never verified.

Sigstore's keyless-OIDC model replaces long-lived keys with short-lived certificates issued to an OIDC identity at sign time. Trust decisions are expressed as policy on OIDC claims (e.g. "accept signatures from https://github.com/org/repo/.github/workflows/release.yml@refs/tags/*") rather than as lists of key fingerprints. Rotation is automatic — certificates expire in minutes — and the Rekor log makes historical signatures auditable.

Canonical instance in this wiki: GitHub immutable-release attestations

GitHub's immutable-releases GA (2025-10-28) emits release attestations in Sigstore bundle format. This is a deliberate interop choice: consumers verify with the gh attestation verify CLI, with cosign, with any Sigstore-compatible Kubernetes admission controller (Kyverno, Sigstore policy-controller), or with language-SDK verifiers in their CI/CD pipelines. GitHub does not require consumers to run GitHub-specific verifier software — the bundle is self-describing and verifiable by any Sigstore tool.

(Source: sources/2025-10-31-github-immutable-releases-ga)

The three-component flow

1. Build time
   GitHub Actions publishes release ──► requests Fulcio cert
                                        (OIDC: workflow identity)
                                        ──► receives short-lived cert

2. Sign time
   GitHub signs release asset digests with cert's key
                ──► uploads signature + cert + payload digest
                    to Rekor (transparency log)
                ──► packages into Sigstore bundle

3. Ship time
   Sigstore bundle attached to release artifact

4. Verify time (consumer)
   cosign / gh attestation verify / Kyverno / ...
     ──► verifies signature against cert chain
     ──► verifies Rekor inclusion proof
     ──► evaluates trust policy on OIDC claims
     ──► recomputes artifact digest, compares to bundle

Verification does not require contact with GitHub.

Ecosystem breadth

Sigstore bundles are consumed by:

  • Container registries: Docker Hub, GitHub Container Registry, Google Artifact Registry — sign/verify container images.
  • Kubernetes admission: Kyverno, Sigstore policy-controller — reject unsigned or untrusted images at pod-admission time.
  • Package managers: npm (provenance attestations), PyPI (trusted publishing + sigstore), RubyGems, Maven Central.
  • CI/CD: GitHub Actions, GitLab CI, CircleCI — sign build outputs during the pipeline.
  • OS distros: Kubernetes releases, Homebrew, select Linux distributions.

What Sigstore is not

  • Not a replacement for enforcement. Sigstore provides portable signed attestations; it does not prevent a platform from serving a modified artifact. Signing is half the supply-chain control; server-side immutability (as in publish-time immutability) is the other half.
  • Not a permission system. Sigstore verifies what signed this; authorising whether this signer should be trusted is the consumer's trust-policy decision.
  • Not a secret store. Keyless signing means no long-lived private keys for Sigstore to lose — the whole architecture is built around avoiding that problem.

Seen in

Last updated · 200 distilled / 1,178 read