cloudparts

Sigstore

Signing for releases, images and packages without keys to manage: a short-lived certificate tied to a login or CI job, and a public log of every signature.

OpenSSF · Graduated
What it is
CI/CD pipelines
Used for
Artifact registries
Type
Open source
Made by
Open Source Security Foundation
Foundation
Open Source Security Foundation, graduated. Part of the Linux Foundation
License
Apache 2.0
Facts checked
28 October 2026
Website Source code

What it is

Sigstore replaces long-lived signing keys with identities. To sign, a client such as Cosign creates a fresh key pair and asks an OpenID Connect provider for a token that says who is signing: an email account, a cloud service account or a CI job such as a GitHub Actions workflow. Fulcio, Sigstore’s certificate authority, checks the token and issues a short-lived certificate that binds that identity to the public key. The client signs, throws the private key away, and records the artifact’s digest, the signature and the certificate in Rekor, an append-only transparency log. A verifier checks the signature, checks that the certificate names the identity it expects, for example a given repository’s release workflow, validates the certificate against Sigstore’s root of trust and confirms the entry is in Rekor.

The project runs Fulcio and Rekor as a free public-good service, generally available since October 2022 with a 99.5% uptime objective, and organisations can run their own. Cosign signs container images, storing signatures in the registry with the OCI 1.1 referrers mechanism, as well as files, SBOMs and attestations such as SLSA provenance. npm has used Sigstore for package provenance since 2023, PyPI for attestations since November 2024, and Kubernetes signs its release images and binaries with it. Rekor v2, a cheaper log built on tiles, became generally available in October 2025 while v1 went into maintenance. Sigstore graduated in the OpenSSF in March 2024; Cosign’s latest release is 3.1.4, from October 2026.

Why teams pick it

  • No private keys to store, rotate or lose: each key signs once and is thrown away
  • Verification names a person or CI workflow instead of a key fingerprint, so “built by this repository’s release job” can be checked
  • A free public instance already used by npm, PyPI and Kubernetes, and supported by registries such as Harbor
  • Every signature is in a public log, so maintainers can watch for signatures made in their name

Watch out for

  • The public log is public: the signer’s identity, such as an email address, and the artifact digest are visible to anyone
  • Keyless signing depends on the public services being up; in February 2023 rate limits left some Kubernetes patch-release images unsigned
  • A signature only proves who signed: verifiers must pin the expected identity and issuer, or any valid identity passes
  • Rekor v2 drops the search index, signed timestamps and most entry types, so older tooling built on v1 has to change

Alternatives

What all ci/cd pipelines have in common →Compare side by side →
Argo CDOpen sourceGitOps delivery for Kubernetes: a controller in the cluster keeps what’s running identical to the manifests in a Git repository.CodecovCommercialA hosted code coverage service: CI jobs upload the coverage reports their tests produce, and Codecov merges them per commit and reports on each pull request how well the changed lines are tested, with a status check that can block the merge.GitHub ActionsCommercialCI/CD built into GitHub: YAML workflows in the repository run on GitHub’s VMs or your own machines whenever something happens in the repo.JenkinsOpen sourceThe self-hosted automation server much of CI started on: a Java controller that hands jobs to agents, more than 2,300 plugins, and pipelines written as a Jenkinsfile.KernelCIOpen sourceContinuous integration for the upstream Linux kernel: it builds kernel trees in many configurations, boots and tests them on real boards in community labs, and collects results from other kernel CI systems in one public database.TektonOpen sourceBuilding blocks for CI/CD systems as Kubernetes resources: each Task runs as a pod, each step in it as a container, and Pipelines chain Tasks together.

How it fits with other technologies

Sign an image in CI with no key, then verify who signed it · bash

# In a GitHub Actions job with `id-token: write`: no key, just the job’s identity
cosign sign --yes ghcr.io/acme/api@sha256:4f1c9e...

# Anywhere: accept only signatures from this repository’s release workflow
cosign verify ghcr.io/acme/api@sha256:4f1c9e... \
  --certificate-identity-regexp '^https://github.com/acme/api/.github/workflows/release.yml@' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com

See it in a real stack

No architecture uses Sigstore yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2021–2026

Signing software usually meant generating a long-lived key, guarding it and getting users to trust it. The Linux Foundation announced Sigstore on March 9, 2021 with Red Hat, Google and Purdue University as founding members, to make signing release files, container images and binaries easier to adopt and free, with signing records kept in a public log designed to resist tampering. Luke Hinds of Red Hat said it would let “all open source communities” sign their software; Dan Lorenc of Google said it aimed “to make all releases of open source software verifiable”.

The community ran a best-effort public instance through 2021 and 2022. On October 25, 2022 Fulcio and Rekor reached 1.0 and general availability, with an uptime objective, round-the-clock on-call and a third-party audit whose findings had been fixed. Large registries followed: Kubernetes signed its images from version 1.24 in 2022, npm launched provenance in April 2023 and PyPI made attestations generally available in November 2024. Sigstore graduated in the OpenSSF in March 2024, and in October 2025 Rekor v2 moved the log to a tile-based backend to cut running costs.

Why it’s built this way

Short-lived keys certified to an identity
Guarding long-lived keys is the hard part of signing. Binding a throwaway key to an OIDC identity in a short-lived certificate removes key management and lets verifiers reason about who signed, not which key.
A public, append-only transparency log
A certificate that expires soon after signing can’t be checked later on its own. Recording every signing event in Rekor proves it happened while the certificate was valid, and lets anyone audit or monitor signatures made with their identity.
A free public-good service
Making signing as easy as running one command needed a certificate authority and log that every project could use without setting anything up, run by the community rather than a vendor.

Timeline

  1. 2021

    Announced by the Linux Foundation on March 9 with Red Hat, Google and Purdue

  2. 2022

    Kubernetes 1.24 images signed in May; Fulcio and Rekor 1.0 and general availability on October 25

  3. 2023

    npm package provenance built on Sigstore, in April

  4. 2024

    Graduates in the OpenSSF in March; PyPI attestations generally available in November

  5. 2025

    Rekor v2 generally available in October

  6. 2026

    Cosign 3.1.4 released in October

Sources11 · facts checked 28 October 2026

Improve this page on GitHub