Sigstore and Keyless Signing

TL;DR: With Sigstore, the signer creates an ephemeral key pair, proves its identity through an OIDC token (a person's account or a CI job's workload identity), and receives a certificate valid for about ten minutes from the Fulcio certificate authority binding the public key to that identity. It signs, records the signature and certificate in the Rekor transparency log, and discards the private key. Verifiers check the signature, that the certificate chains to Fulcio, that the identity matches what they expect (for example "this repository's release workflow"), and that the log entry proves signing happened while the certificate was valid. There is no long-lived key to steal; the risk moves to the identity provider and to verification policy.

The problem with long-lived keys

Traditional code signing depends on a private key that lives for years. Keys get lost, leaked from CI secrets, stolen from developer laptops, or never rotated. Open-source maintainers in particular rarely manage keys well, so most open-source artifacts were historically unsigned. Sigstore, started in 2021 and now an OpenSSF project, was designed to make signing easy enough to be the default and to remove the long-lived key.

The pieces

Signing and verifying

The log entry is what makes a ten-minute certificate useful years later: it proves the signature was created inside the certificate's validity window, so expiry does not invalidate it.

What the transparency log adds

• Detection of misuse. Every signature for an identity is public. A maintainer can monitor the log for signatures made with their identity that they did not make, as domain owners monitor Certificate Transparency.
• Non-equivocation. The log is append-only and auditable, so it cannot show different histories to different verifiers without detection.
• Evidence of when. In Rekor v1 the log's signed entry time anchored the signature. Rekor v2 moved that job to a separate timestamp authority, as the next section explains.

Rekor v2: time comes from a timestamp authority

Sigstore released Rekor v2 as generally available in October 2025, and it changes one detail that verification policies depend on. The new log is tile-based, served from a single entries endpoint, and sharded by year, with shard locations distributed through Sigstore's TUF trust root. It no longer returns signed timestamps with its proofs. Instead, clients obtain a signed timestamp from a timestamp authority: Sigstore runs a public one, and organisations can run their own. Cosign 2.6.0 and the Go, Python and Java clients support v2, and Rekor v1 is in maintenance mode.

So the question "how does a ten-minute certificate verify years later?" now has a two-part answer: the log's inclusion proof shows the signature was recorded and cannot be quietly removed, and a trusted timestamp shows it was made inside the certificate's validity window.

Where the risk moves

Sigstore removes key theft but not trust:

• The identity provider. If an attacker can obtain an OIDC token for the maintainer's account or the release workflow, they can sign as that identity. Protect accounts with phishing-resistant MFA and restrict which CI events can mint tokens.
• Verification policy. Checking "signed by anyone via Sigstore" is close to worthless. Policies must pin the expected identity and issuer, such as a repository, a workflow file and a branch or tag pattern.
• The build. A signature from the correct release workflow is only as good as that workflow's inputs, which is why Sigstore is usually paired with SLSA provenance.
• Privacy. Identities in the public log are visible; use workload identities rather than personal emails for automated releases.

Where it is used

As of November 2026: Cosign signatures and verification for container images and Kubernetes admission policies; npm package provenance (launched 2023) and PyPI digital attestations (PEP 740) built on Sigstore; and the OpenSSF model signing specification, which signs model directories with Sigstore by default. These evolve quickly; check the current documentation before relying on a specific feature.

Trusted publishing, and why it arrived when it did

Package registries adopted the same idea for publishing: instead of a long-lived API token stored in CI, the CI job exchanges its OIDC identity for a short-lived publishing credential.

GitHub's artifact attestations fit the same picture. On their own they meet SLSA v1.0 Build Level 2; generated inside a reusable workflow, which isolates the signing step from the calling repository's code, they reach Build Level 3. Verification should pin the signer workflow or repository, not just the organisation.

Worked example: a Python package release policy

A consumer's policy for acme-lib requires a PEP 740 attestation whose certificate identity is https://github.com/acme/lib/.github/workflows/release.yml on a ref matching refs/tags/v*, whose issuer is GitHub Actions' token service, and whose signing time falls inside the certificate's ten-minute window by the timestamp evidence.

An attacker phishes a maintainer's PyPI password. If the project publishes only through trusted publishing and holds no API tokens, there is nothing to upload with. If the attacker can also push a tag to the repository, the release workflow runs and produces a legitimately attested release, so the remaining controls are branch and tag protection and required reviewers on the release environment.

Misconceptions interviewers listen for

• "Keyless means no keys." It means ephemeral keys and no long-lived secret to steal.
• "Rekor gives me the timestamp." True for v1; with v2 a separate timestamp authority provides it.
• "Trusted publishing stops compromised maintainers." It removes stealable tokens; a compromised repository or workflow still publishes legitimately.
• "Any Sigstore signature is good." Policy must pin the identity and issuer.

How this shows up in interviews

"How does keyless signing work, and what does the transparency log add?" probes whether you understand that "keyless" means "no long-lived key", not "no keys". Strong answers walk through OIDC, Fulcio, the ephemeral key and Rekor, explain why a ten-minute certificate still verifies later, and insist on identity-pinned verification policies. Mention where the trust moved: the identity provider and the build.

Say it in 30 seconds: "Sigstore replaces long-lived signing keys. The signer makes an ephemeral key, proves its identity with an OIDC token from a person or a CI workflow, and Fulcio issues a ten-minute certificate binding the key to that identity. The signature goes into Rekor, a public append-only log, and the key is thrown away. Verifiers check the signature, the chain, that the identity is exactly the expected workflow, and that the log shows it was signed while the cert was valid. The risk moves to the identity provider and the build."