Sigstore is an open-source project that makes signing and verifying software easy by removing the hardest part of traditional code signing: managing private keys. Instead of generating and guarding a long-lived signing key, developers authenticate with an identity they already have — a CI workload identity or an OIDC account — and Sigstore issues a short-lived certificate, records the signing event in a public transparency log, and lets anyone verify the result. Maintained under the Open Source Security Foundation (OpenSSF) and the Linux Foundation, Sigstore reached general availability for its core components in 2022 and now underpins signing across major software ecosystems.
Why It Matters
Traditional code signing failed in practice not because the cryptography was weak, but because key management was hard. Teams generated long-lived signing keys, stashed them in a build server or a shared vault, and then had to keep them secret for years. Those keys got leaked, stolen, or committed to repositories, and a stolen signing key lets an attacker sign malware that every downstream consumer trusts. The overhead was high enough that most open-source projects simply did not sign at all.
Sigstore removes both problems at once. There is no long-lived key to steal because signing keys are generated on demand and discarded within minutes, and there is no key-management burden because identity is provided by systems developers already use. That low friction is why signing adoption has surged: package registries, container ecosystems, and language communities have adopted Sigstore precisely because it makes "sign everything, verify everything" realistic rather than aspirational.
How It Works
Sigstore's model is called keyless signing, though a key is still used — it just does not persist. The flow ties together three services:
- Cosign is the client tool that signs and verifies artifacts, most famously container images but also SBOMs, attestations, and blobs. It orchestrates the whole process.
- Fulcio is a certificate authority that issues short-lived code-signing certificates. When you authenticate through an OIDC identity provider, Fulcio issues a certificate — valid only for a matter of minutes — that binds the ephemeral signing key to your verified identity.
- Rekor is an append-only, tamper-evident public transparency log. Every signing event is recorded there, so even after the short-lived certificate expires, anyone can prove the signature was made by that identity at that time.
In practice: you authenticate, Fulcio issues a brief certificate for your identity, Cosign signs the artifact with the ephemeral key, the event is logged in Rekor, and the private key is thrown away. Verification later checks the signature against the certificate's recorded identity and confirms the entry exists in the transparency log — no shared secret required.
Key Parts of Sigstore
| Component | Role | What it replaces |
|---|---|---|
| Cosign | Signs and verifies artifacts and attestations | Ad hoc, per-ecosystem signing tools |
| Fulcio | Issues short-lived certificates bound to an OIDC identity | Long-lived signing keys and manual PKI |
| Rekor | Public, append-only transparency log of signing events | Trust based on unaudited, private records |
| OIDC identity | Proves who is signing | Passwords and shared signing credentials |
Best Practices
- Sign from CI using workload identity. Signing inside a pipeline binds the signature to the build job's identity, which is exactly the provenance you want, and avoids any human handling a key.
- Verify identity, not just validity. A signature being cryptographically valid is not enough — enforce that it came from the expected identity, such as your organization's build workflow, before trusting the artifact.
- Check the transparency log. Confirming the signing event is recorded in Rekor is what makes an expired short-lived certificate still verifiable and catches backdated or forged records.
- Sign attestations, not just artifacts. Use Cosign to sign SBOMs and provenance attestations too, so the metadata that drives your policy is as trustworthy as the artifact itself.
- Pin your verification policy. Decide which identities and issuers are acceptable and enforce that policy consistently across environments rather than verifying by hand.
How Safeguard Helps
Safeguard builds on Sigstore rather than reinventing signing. The Safeguard CLI uses keyless signing to sign and verify artifacts and attestations directly in your pipeline, so adopting Sigstore is a matter of turning it on rather than assembling Cosign, Fulcio, and Rekor yourself. Signed SBOMs and attestations land in SBOM Studio alongside the component inventory, giving you a single place to confirm that every artifact's metadata carries a verifiable signature.
At policy time, Griffin AI checks that artifacts are signed by the expected identities and correlates any signing gaps with the vulnerability and reachability picture, so an unsigned or wrongly-signed critical artifact surfaces as a prioritized risk instead of slipping through. For related supply chain topics, browse the concepts library.
Create a free account to start signing and verifying with Sigstore, or read the documentation to see how it integrates.
Frequently Asked Questions
Is Sigstore really keyless if it still signs with a key? "Keyless" refers to there being no long-lived key for you to generate, store, and protect. A signing key is still created for each operation, but it exists only for the few minutes of signing and is then discarded. Because there is no persistent secret, there is nothing for an attacker to steal later, which is the entire security benefit.
What is the transparency log for? The transparency log, Rekor, is an append-only public record of every signing event. Since Sigstore's signing certificates expire within minutes, the log is what lets anyone verify — long after the fact — that a given identity signed a given artifact at a given time. It also makes tampering detectable, because entries cannot be silently altered or removed.
Which ecosystems actually use Sigstore? Sigstore is used widely across the software supply chain: container image signing, language package registries adopting signed provenance and attestations, and Kubernetes-native policy tooling that verifies signatures before admitting workloads. Its adoption by mainstream registries is what pushed keyless signing from a niche technique into a default expectation.
Do consumers need special tools to verify Sigstore signatures? Consumers need a verifier such as Cosign or a platform like Safeguard that performs the check, plus access to the transparency log. The verification itself is straightforward; the meaningful work is defining which signing identities you trust, which is a policy decision rather than an infrastructure hurdle.