On October 25, 2022, the Sigstore project announced general availability of its free software signing service. This was a milestone years in the making — one that addressed a fundamental gap in software supply chain security: the ability for any developer to cryptographically sign their software artifacts without the complexity and cost of traditional code signing infrastructure.
Sigstore didn't just make signing easier. It rethought the entire model.
Why Signing Mattered (and Why Nobody Did It)
Cryptographic signing has been a known best practice for decades. The concept is simple: the author of a piece of software signs it with their private key, and anyone can verify the signature using the corresponding public key. If the software has been tampered with, the signature won't verify.
In practice, almost nobody did it — especially in the open source ecosystem. The reasons were well-understood:
Key management is hard. Developers had to generate, store, protect, and rotate long-lived signing keys. If a key was compromised, every artifact signed with it was suspect. If a key was lost, the developer couldn't sign new releases.
Certificate authorities are expensive and complex. Traditional code signing certificates cost money and require identity verification processes that don't map well to the open source world.
Distribution is unsolved. Even if you sign your artifacts, how do consumers find and verify your public key? There was no universal, trusted directory of developer signing keys.
The developer experience was terrible. GPG, the most common signing tool, is notoriously difficult to use. The cognitive overhead of signing every release discouraged adoption.
The result: the vast majority of open source packages were distributed without any cryptographic verification of authenticity or integrity.
What Sigstore Does Differently
Sigstore reimagined software signing from the ground up, making three key design decisions that set it apart:
Keyless Signing
Instead of requiring developers to manage long-lived signing keys, Sigstore uses short-lived certificates tied to the developer's existing identity (such as a GitHub or Google account). The developer authenticates via OpenID Connect, receives an ephemeral signing certificate from Sigstore's certificate authority (Fulcio), signs the artifact, and the certificate expires within minutes.
This eliminates key management entirely. There are no keys to store, protect, rotate, or revoke.
Transparency Log
Every signing event is recorded in an append-only transparency log called Rekor. This log serves as a public, immutable record of when an artifact was signed and by whom. Even though the signing certificates are short-lived, the transparency log provides a permanent record that can be used for verification at any point in the future.
The transparency log also enables monitoring. Anyone can watch the log for signing events and detect unauthorized signatures — similar to how Certificate Transparency logs help detect misissued TLS certificates.
Identity-Based Trust
Instead of trusting keys, Sigstore enables trust based on identity. You can verify that a package was signed by maintainer@example.com or by a specific GitHub Actions workflow in a specific repository. This is more meaningful than trusting an opaque cryptographic key, because it connects the signature to an identity that consumers can evaluate.
The Sigstore Components
Sigstore is actually a suite of tools and services:
Fulcio — The certificate authority that issues short-lived signing certificates based on OIDC identity verification.
Rekor — The transparency log that records signing events. Rekor entries include the signed artifact's digest, the ephemeral certificate, and a timestamp from a trusted timestamping service.
Cosign — A tool for signing and verifying container images and other OCI artifacts. Cosign integrates with container registries to store signatures alongside the images they sign.
Gitsign — A tool for signing git commits using Sigstore, replacing GPG-based commit signing with keyless, identity-based signing.
Policy Controller — A Kubernetes admission controller that enforces signature verification policies, preventing unsigned or incorrectly signed container images from being deployed.
What GA Meant
The general availability announcement meant several things:
- Production stability guarantees. The public-good Sigstore infrastructure (Fulcio, Rekor) committed to production-level availability and backward compatibility.
- Ecosystem adoption. npm, PyPI, and other registries could build on Sigstore as a stable foundation for package provenance.
- Enterprise confidence. Organizations could adopt Sigstore knowing that the infrastructure would be maintained and supported.
- Audit and compliance readiness. The transparency log provided the kind of auditable record that compliance frameworks increasingly require.
Adoption Momentum
By the time of the GA announcement, Sigstore was already seeing significant adoption:
- Kubernetes was signing all release artifacts with Sigstore
- npm was building Sigstore-based package provenance
- PyPI was developing Sigstore integration for package signing
- Homebrew adopted Sigstore for signing macOS packages
- GitHub Actions integrated with Sigstore for automated signing in CI/CD workflows
- Over 4 million signatures had been recorded in the Rekor transparency log
The Supply Chain Impact
Sigstore addresses several critical gaps in software supply chain security:
Provenance Verification
With Sigstore, consumers can verify that a package was built by a specific CI/CD workflow from a specific source repository. This connects the published artifact to its source code, closing the gap that supply chain attacks exploit.
Tamper Detection
Any modification to a signed artifact invalidates its signature. This prevents attackers from modifying packages after they've been signed — whether on the registry, in transit, or in a CDN cache.
Accountability
The transparency log creates an auditable trail of who signed what and when. If a malicious artifact is discovered, the signing identity can be traced and investigated.
Reduced Maintainer Risk
Because Sigstore uses short-lived certificates, there are no long-lived keys to steal. This reduces the value of compromising a maintainer's machine — the attacker can't extract a signing key to use at their leisure.
Challenges Ahead
Despite the progress, significant challenges remained:
Consumer-side verification. Signing is only useful if consumers verify signatures. As of late 2022, most package managers didn't verify Sigstore signatures by default. Getting verification into the default path for npm install, pip install, and similar commands was a multi-year effort.
Trust policy definition. Sigstore tells you who signed an artifact, but deciding which signers to trust requires policy. Organizations need tooling to define and enforce signing policies (e.g., "only deploy images signed by our CI/CD system").
Adoption at scale. While high-profile projects adopted Sigstore, the long tail of smaller projects — which collectively represent a huge attack surface — was still largely unsigned.
Offline verification. Sigstore's verification process can require network access to check the transparency log. Environments with restricted network access need alternative verification paths.
How Safeguard.sh Helps
Safeguard.sh integrates with Sigstore to provide comprehensive signature verification across your software supply chain. Our platform verifies Sigstore signatures on container images and packages, enforces signing policies that define which identities are trusted for which artifacts, and monitors the Rekor transparency log for unexpected signing events. By incorporating Sigstore verification into your security posture, Safeguard.sh ensures that the provenance guarantees Sigstore provides are consistently enforced across your entire software portfolio.