Sigstore: Software Signing for Everybody

Sigstore: Software Signing for Everybody. In 2022, Zachary Newman, John Speed Meyers, and Santiago Torres-Arias presented this work at the Conference on Computer and Communications Security. They tackled a practical software-supply-chain problem: how to offer signing as a public service without requiring every developer or automated build to protect a persistent signing key. Their design connects authenticated identities to short-lived certificates, public logs, trust updates, and usable client tools. By the end, you should understand how that signing path works, what verification checks, and why a valid Sigstore signature still does not establish that the code is safe.

Earlier ecosystem measurements illustrate the adoption problem. Signing was rare among the latest RubyGems releases. In another package index, only a small minority of projects advertised signatures, and far fewer users downloaded those signatures for verification. Sigstore’s term “keyless signing” does not mean cryptographic keys disappear. The client creates a temporary key, receives a certificate connecting that key to an authenticated identity, signs the artifact, and destroys the private key. The signer therefore avoids managing a persistent signing key.

The system question is whether a signing service can connect a release to an authenticated person or workload, leave auditable evidence, and keep its trust material current while removing persistent-key custody from the signer. The researchers answered with a deployed combination of familiar mechanisms rather than a new cryptographic primitive. The practical test is not merely whether the signature is mathematically valid. Evidence checks connect the artifact to records in the public logs. Identity checks confirm that the certificate and identity provider identify the expected signer. Authorization rules then determine whether that signer and provider are permitted for the artifact.

Here is the signing path. A client creates a temporary key pair. Fulcio, Sigstore’s certificate authority, checks an identity-provider token and issues a certificate binding the public key to the authenticated user or workload. In the studied deployment, that certificate was valid for 10 minutes. The client signs the artifact and destroys the private key. The certificate enters one transparency log, while the artifact signature or an attestation—a signed claim about the build—enters Rekor, an append-only log. The Update Framework distributes trusted Fulcio and Rekor material; multiple offline root keys govern updates, together with rotation, freshness checks, and revocation.

For operational evidence, the authors conducted 7 guided interviews that followed a prepared structure while allowing follow-up questions. Participants had experience with Kubernetes, RubyGems, a Java client, or open-source use. The authors also repeated timing tests on a workstation. In that setup, online verification spent roughly 1.5 seconds on network services and trust updates. That number characterizes the evaluated setup and should not be treated as universal production latency. Likewise, the interviews provide implementation experience rather than a population-wide adoption measurement.

A snapshot of identity providers represented in Rekor offered another view of actual service use. GitHub Actions accounted for 80.2% of the observations, and Google accounted for 17.5%; the remaining observations came from Kubernetes, GitHub OAuth, and other issuers. This describes which identity providers appeared in that snapshot. By itself, it does not measure whether downstream systems checked identities or enforced authorization policies.

The security analysis allows for network or repository compromise, but assumes the attacker does not initially control a developer account or signing key, cannot control a log for a prolonged period, and cannot replace the client or trust-root software. Those boundaries matter: a stolen developer or automated-build identity can authorize a malicious release, while destroying the temporary key only limits later reuse. The service components introduce separate failure cases. A compromised identity provider can impersonate its users, Fulcio can issue false certificates, and a compromised log can deny service or present inconsistent histories. Public-identity privacy, service concentration, and the monitoring burden also remain unresolved.

For release and identity teams, the operational takeaway is to stop treating signature validation as the whole decision. Identity checks should validate the certificate chain and lifetime, expected identity provider, and signer identity. Artifact verification should confirm the signature, while log verification should confirm inclusion in the public records. A separate policy must map each artifact to permitted identities and providers. Teams also need independent log monitoring and a tested trust-root recovery path for service compromise. Separately, repositories need protected metadata to resist rollback and frozen old releases. These controls still do not prove that signed code is benign; they authenticate an identity and its claim.

Sigstore’s demonstrated contribution is a deployed public service for software signing, combining identity authentication, short-lived certificates, and client tooling. It records certificates and signed artifacts through two kinds of transparency logging. Trust-root distribution keeps the verification material current. The authors concluded that signing adoption had increased, while repository integration and downstream use still needed work. Security architects, release engineers, and identity teams can use this model to remove persistent signer-key custody and attach identities to build claims. They should not infer that a signed release is harmless, that its account was uncompromised, or that its identity and logging services require no monitoring or recovery plan.