Sigstore is a free, open source infrastructure for signing, verifying, and recording the provenance of software artifacts — container images, packages, binaries, and SBOMs — without requiring maintainers to generate or manage long-lived private keys. Launched in March 2021 under the Linux Foundation with backing from Google, Red Hat, and Chainguard, Sigstore became a CNCF incubating project in April 2023. It solves a specific problem exposed by incidents like the 2020 SolarWinds compromise: traditional code signing requires developers to protect a private key indefinitely, and a stolen key can sign malicious code that looks legitimate for years. Sigstore replaces that model with short-lived, identity-bound certificates and a public, tamper-evident transparency log. Its three core components — Fulcio, Rekor, and Cosign — now sign releases for npm, PyPI, Kubernetes, and thousands of other projects. This glossary entry breaks down how the system works and where it fits into a defensive supply chain security program.
How does Sigstore let you sign code without managing keys?
Sigstore uses "keyless signing," where a developer's identity — not a stored private key — becomes the root of trust for a signature. When a developer or CI job runs cosign sign, the tool generates a brand-new ephemeral key pair in memory, then authenticates to Fulcio (Sigstore's certificate authority) using an OpenID Connect (OIDC) token from a provider like GitHub Actions, Google, or Microsoft. Fulcio verifies that OIDC token and issues a short-lived X.509 certificate — typically valid for around 10 to 20 minutes — that binds the ephemeral public key to the verified identity, such as a specific GitHub Actions workflow file and repository. The signer uses the private key to sign the artifact, then discards it immediately. Because the key never persists, there's nothing for an attacker to steal from a laptop, a CI secret store, or a build server months later; a compromised signature can only happen during that narrow signing window, and it is tied to a verifiable identity rather than an anonymous key fingerprint.
What is Rekor and why does it matter for verification?
Rekor is Sigstore's public transparency log, and it matters because it lets anyone independently verify that a signature existed at a specific point in time, without trusting the signer's word or Sigstore's servers after the fact. Every signing event — the certificate, the public key, and a hash of the artifact — is appended to a Merkle-tree-based log hosted at rekor.sigstore.dev, which is append-only and cryptographically auditable, similar in design to Certificate Transparency logs used for HTTPS certificates. Once an entry lands in Rekor, it cannot be silently altered or deleted; any tampering would break the Merkle tree's inclusion proofs, which are publicly checkable. This is what closes the gap left by Fulcio's short-lived certificates: since the signing cert expires in minutes, Rekor's timestamped log entry is the durable evidence that verification tools like cosign verify check against months or years later to confirm a signature was valid when it was made, not forged retroactively.
Which major package ecosystems actually use Sigstore in production?
npm, PyPI, and Kubernetes have all shipped production Sigstore integrations. npm added Sigstore-backed provenance attestations starting with npm CLI 9.5.0 in April 2023, letting maintainers publish packages with a verifiable statement of which GitHub Actions workflow and commit produced the published tarball — visible today as the "Provenance" badge on npmjs.com package pages. PyPI rolled out Trusted Publishing using OIDC and Sigstore infrastructure in April 2023, and formalized digital attestations for packages under PEP 740, adopted in 2024, which lets PyPI verify that an uploaded wheel or sdist was built by the claimed CI workflow rather than uploaded via a stolen API token. Kubernetes SIG Release began signing all release artifacts — binaries, images, and the checksum file — with Cosign starting with Kubernetes 1.24 in April 2022, and every Kubernetes release since has shipped with signatures verifiable against the public Rekor log. Sigstore's own adoption tracker also lists sign-in from projects like Homebrew's binary distribution pipeline and various Kubernetes-ecosystem tools such as Helm and Argo.
How does Sigstore relate to SLSA and SBOMs?
Sigstore is the signing mechanism that makes SLSA provenance and SBOM attestations trustworthy rather than just self-asserted text files. SLSA (Supply-chain Levels for Software Artifacts) defines a framework for describing how a build was produced — which source repo, which builder, which parameters — but that provenance document is only useful if you can verify it wasn't fabricated after the fact. Cosign can attach an SBOM (in SPDX or CycloneDX format) or a SLSA provenance statement to a container image or artifact as a signed, in-toto formatted attestation, then log the attestation's signature in Rekor. GitHub's own build provenance for Actions, generalized available since 2023, uses exactly this pattern: it generates a SLSA-compliant attestation and signs it through Sigstore's public-good Fulcio and Rekor instances at no cost to the maintainer. The practical result is that a consumer pulling an image or package can run one verification command and confirm both "what's inside this artifact" (the SBOM) and "how it was built and by whom" (the provenance) against a tamper-evident log, instead of trusting a plaintext JSON file that ships alongside the artifact with no cryptographic binding to it.
What are Sigstore's limitations from a defender's perspective?
Sigstore verifies that an artifact was signed by a specific, authenticated identity — it does not verify that the artifact is free of vulnerabilities or malicious code. A compromised GitHub Actions workflow with valid OIDC permissions, or a malicious insider with legitimate publish rights, can still produce a perfectly valid Sigstore signature over a backdoored package, exactly as happened in incidents like the 2021 codecov bash uploader compromise and the 2022 PyTorch dependency confusion attack, neither of which a signature alone would have caught. Verification is also only as strong as the policy enforcing it: if a CI pipeline pulls a package without running cosign verify and checking the certificate identity against an expected OIDC subject (for example, a specific repo and workflow path), the signature provides no protection even if it exists. And because Fulcio's public-good instance issues certificates to any OIDC identity a provider will vouch for, teams still need their own policy layer — deciding which identities, repos, and workflows are trusted signers — rather than treating "it has a Sigstore signature" as equivalent to "it is safe."
How Safeguard Helps
Sigstore tells you who signed an artifact and when; Safeguard determines whether the vulnerable or unsigned code that signature covers is actually reachable and exploitable in your running applications. Safeguard's reachability analysis traces call paths from your application entry points into third-party dependencies to filter out CVEs and unsigned-package alerts that never execute, cutting through the noise that pure signature-checking or CVE scanning produces on its own. Griffin, Safeguard's AI reasoning engine, correlates Sigstore/Rekor provenance gaps, SBOM data, and reachability context to explain in plain language why a specific unsigned or anomalously-signed dependency matters for your codebase. Safeguard generates and ingests SBOMs (SPDX and CycloneDX) across your build pipeline so you have a verifiable inventory to check against Sigstore attestations in the first place, and where a fix is available, Safeguard opens an auto-fix pull request that updates the dependency and re-verifies its provenance rather than leaving that work to a security team's backlog.