Sigstore Explained (2026): Cosign v3, Rekor at 3.6 Billion, Keyless Signing

I sign every release artifact I ship, and for most of the last decade that meant a GPG key on a laptop, a passphrase in a password manager, and a quiet hope that nobody ever asked me to rotate it. Sigstore replaced that with something I actually trust: keyless signing, where the signature is bound to a CI workflow identity rather than a long-lived key, and every signature lands in a public transparency log. This post explains how Sigstore artifact signing works in 2026, what cosign, Fulcio and Rekor each do, what changed with cosign v3 and Rekor v2, how npm, PyPI and GitHub use it, and the part people skip: a signature only helps if someone checks it against the right identity.

What is Sigstore, and what problem does it solve?

Sigstore is an open-source project under the OpenSSF that makes signing software cheap enough that people actually do it. The hard part of code signing was never the cryptography. It was key management: generating keys, protecting them, distributing the public half, rotating them, and revoking them after the inevitable leak. Most open-source projects simply did not sign, and the ones that did published a fingerprint that almost nobody verified.

Sigstore's answer has three moving parts. Cosign is the client that signs and verifies container images, blobs and attestations. Fulcio is a certificate authority that issues short-lived X.509 certificates tied to an OpenID Connect identity. Rekor is an append-only transparency log that records every signing event so anyone can audit it later. The project also runs a free "public good" instance of Fulcio and Rekor, and a TUF repository that distributes the root certificates and log keys clients need. Client libraries exist for Go, Python, JavaScript, Java and Rust. (There is also a C89 sigstore-c that runs on DOS, but it was published on 1 April 2026 and its own announcement says it is not an official client library.)

The result is that a GitHub Actions workflow can sign an image with no secret stored anywhere, and a verifier on the other side of the world can check not just "was this signed" but "was this signed by the release workflow of this repository, on this tag".

How keyless signing works: OIDC, Fulcio and Rekor

"Keyless" is a slightly misleading name. There is a key pair; it just lives for seconds and is never stored. The flow looks like this:

1. The signer (a CI job, or a developer at a browser) obtains an OIDC identity token from its provider: GitHub Actions, GitLab, Google, Microsoft and others.
2. Cosign generates an ephemeral key pair and sends the public key plus the token to Fulcio.
3. Fulcio checks the token and issues a certificate whose subject alternative name is the identity: an email address, or for GitHub Actions a URI such as https://github.com/ORG/REPO/.github/workflows/release.yml@refs/tags/v1.2.0. Fulcio certificates are valid for 10 minutes and are themselves logged to a certificate transparency log.
4. Cosign signs the artifact digest, writes the signature and certificate to Rekor, gets back an inclusion proof, and throws the private key away.
5. The signature, certificate and proof are packaged as a Sigstore bundle and stored next to the artifact: as an OCI referrer in the registry for images, or as a .sigstore.json file for blobs.

The clever part is step 4 meeting step 3. The certificate expires ten minutes after issue, so how do you verify a signature a year later? Because Rekor recorded the signing event with a timestamp while the certificate was valid. The verifier checks that the log entry exists and that it was integrated during the certificate's validity window. The log replaces revocation: if a token is stolen and used, the misuse is visible in public, and identity owners can monitor the log for signatures they did not make.

What keyless signing does not do is decide who you trust. A valid Fulcio certificate only says "someone with a GitHub Actions token from some repository signed this". Every verification command therefore takes two non-optional inputs: the expected identity (--certificate-identity or a regexp) and the expected issuer (--certificate-oidc-issuer). Cosign 2.0 made both mandatory, which is the single most important design decision in the project.

What changed in 2025 and 2026: cosign v3, Rekor v2 and a paused rollout

Cosign v3 shipped on 8 October 2025 and flipped the defaults that cosign 2.6 had introduced as opt-ins: the standardised Sigstore bundle format, a trusted root file that holds all verification material in one place, and a signing config that tells the client which Fulcio, Rekor and timestamp services to use, so log shards can rotate without a client release. The project says cosign v4 will remove roughly half the CLI flags. The current release is v3.1.4 from 20 October 2026, and you should be on 3.1.3 or later regardless: v3.1.3 fixed GHSA-fx35-mq7g-6g98, a verification bypass using an unexpected public key in a legacy bundle, with a backport to v2.6.5.

Rekor v2 reached GA two days later. It is a rewrite on Tessera, a tile-backed log whose reads are cacheable by a CDN, with only two entry types (hashedrekord for artifacts and dsse for attestations) instead of eleven, yearly shards at URLs like log2025-1.rekor.sigstore.dev, and no built-in search index or signed timestamps (those come from a separate timestamp authority). The plan was to make it the default for the public good instance.

That plan changed. In June 2026 the maintainers wrote that the public instance will keep Rekor v1 as its default log "for the foreseeable future", because v2 breaks older clients and the post-quantum move will break them again; better to break them once. I checked: the production signing config in the root-signing repository still lists only rekor.sigstore.dev as a v1 log. Ecosystems that run their own signing can opt into v2 today.

Signal	Number or date	Source
Rekor v1 entries (3 shards)	3,610,794,558 on 31 Oct 2026	rekor.sigstore.dev/api/v1/log, queried by me
Rekor v2 shard log2025-1	177,127,592 entries	v2 checkpoint endpoint, queried by me
PyPI projects on trusted publishing	more than 50,000	PyPI 2025 review
PyPI uploads via trusted publishing / attested	more than 20% / 17%	PyPI 2025 review
npm trusted publishing GA	31 July 2025	GitHub changelog
Homebrew, PyPI, Maven Central, NVIDIA NGC adoption	May 2024, Nov 2024, Jan 2025, Jul 2025	cosign v3 post
Kubernetes release images signed	beta since v1.26	Kubernetes docs

Three and a half billion log entries is the quiet success story here. I could not find a trustworthy registry-wide percentage for npm packages with provenance, only small samples from vendors, so I have left that out.

npm provenance, PyPI trusted publishing and GitHub artifact attestations

Most developers meet Sigstore without installing cosign, through the package registries.

Trusted publishing is the registry side of keyless. Instead of storing a long-lived API token as a CI secret, you tell PyPI or npm "packages for this project are published by this workflow in this repository", and the registry accepts a short-lived OIDC token from that workflow. It is the same idea as workload identity federation for cloud credentials, applied to publishing. On npm, publishing from GitHub Actions or GitLab CI with trusted publishing generates provenance automatically; consumers check it with npm audit signatures. On PyPI the equivalent is PEP 740 attestations, uploaded alongside the files.

GitHub artifact attestations generalise this to anything you build: binaries, container images, SBOMs. The actions/attest action (v4.2.2; attest-build-provenance is now a thin wrapper over it) signs an in-toto statement with a Fulcio certificate. Public repositories use the public good Sigstore instance and log to Rekor; private repositories use GitHub's own Sigstore instance, which has no transparency log. According to GitHub's docs, attestations on their own give you SLSA v1.0 Build Level 2, and you get Level 3 by running the build in a reusable workflow that isolates it from the calling workflow. On Free, Pro and Team plans attestations only work for public repositories.

SLSA (v1.2 is current) is the vocabulary for how much a provenance statement is worth. L1 means provenance exists; L2 means a hosted build platform signed it; L3 means the platform stops the build from forging its own provenance. Sigstore is the signing mechanism most SLSA provenance uses, which is why the two get conflated. I covered the regulatory side of SBOMs and provenance in the CRA reporting post.

Is a signed artifact a safe artifact?

No, and the 2026 axios compromise is the cleanest illustration I know. On 31 March, two malicious versions, 1.14.1 and 0.30.4, were published through the lead maintainer's compromised npm account and stayed live for about three hours, per the maintainer's postmortem. StepSecurity's analysis of the registry metadata shows the legitimate 1.14.0 was published by GitHub Actions through trusted publishing, while 1.14.1 was pushed manually with a stolen token and carried no trusted-publisher record.

Read that again: the provenance signal was there. A client that required "axios must be published by the axios release workflow" would have refused the malicious version. Almost nothing did, because trusted publishing was an additional path rather than the only one, and because installers do not enforce provenance by default. The postmortem's own fixes are OIDC-only publishing and immutable releases. The same lesson runs through the npm worm year.

There is a second limit. npm's own documentation states that provenance "does not guarantee the package has no malicious code." A signature proves who built it from what. If the attacker controls the source repository, or a poisoned dependency runs inside a legitimate build, the provenance is honest and the artifact is still malicious. Signing narrows the attack to your build system; it does not remove it. That is why the workflow hardening in the GitHub Actions security post matters as much as the signature.

Signing vs SLSA provenance vs SBOM attestations: what each proves

These get lumped together, but they answer different questions, and a verifier should ask the one it cares about:

• A signature says this exact digest was approved by this identity.
• A provenance attestation (SLSA predicate) says which workflow, commit and inputs produced the digest.
• An SBOM attestation says what the builder believed was inside, signed so it cannot be swapped later.

All three can be verified with the same identity check. Here is what that looks like for artifacts you already consume:

# cosign v3.1.4. Verify a Kubernetes release image against the identity
# the Kubernetes release team publishes (from the Kubernetes docs).
cosign verify registry.k8s.io/kube-apiserver-amd64:v1.37.0 \
  --certificate-identity krel-trust@k8s-releng-prod.iam.gserviceaccount.com \
  --certificate-oidc-issuer https://accounts.google.com | jq .

# Verify the npm packages in this project carry valid registry
# signatures and, where published, provenance attestations.
npm audit signatures

# Verify a GitHub artifact attestation for an image (needs gh and a
# registry login); defaults to checking SLSA build provenance.
gh attestation verify oci://ghcr.io/ORG/IMAGE:1.2.0 -R ORG/REPO

The practical walkthrough, signing your own images in GitHub Actions and enforcing signatures at Kubernetes admission with Kyverno, is in the companion guide, how to sign and verify container images with cosign keyless.

What post-quantum Sigstore will change

The October 2026 post-quantum plan is the biggest architectural change since launch. Sigstore will move to ML-DSA, and rather than mixing algorithms, the post-quantum service will be a separate stack with its own ML-DSA-signed TUF root. Keyless signing gets simpler: the transparency log will accept OIDC tokens directly and return a witnessed, timestamped proof, removing the ephemeral key, the short-lived certificate and the separate timestamp. Identities such as emails and private repository names will be stored as hashes. The Rekor v2 rollout is paused while that PQC-ready log is built.

The dates matter for planning: a production PQC public instance is targeted for mid-2027, adoption is opt-in at first, and the classical instance stays supported until a turndown tentatively set for 2029 or 2030. If you build tooling on Sigstore today, the advice is the same one the cosign v3 release gave: use the bundle format, get trust material from TUF instead of hardcoding URLs, and keep your client libraries current.

FAQ

What is the difference between Sigstore and cosign?

Sigstore is the overall project: the Fulcio certificate authority, the Rekor transparency log, the TUF trust root, the public good instance and client libraries in several languages. Cosign is Sigstore's command-line client for signing and verifying container images, files and attestations. You can use Sigstore without cosign, for example through npm, PyPI or GitHub artifact attestations.

Is keyless signing really keyless?

Not literally. Cosign creates a key pair for each signing operation, gets a certificate from Fulcio that is valid for 10 minutes, signs, records the event in Rekor and discards the private key. There is simply no long-lived key to store, rotate or leak, and trust comes from the OIDC identity in the certificate.

Does a valid cosign signature mean an image is safe?

No. It proves the digest was signed by a particular identity, and only if you verify that identity and issuer explicitly. It says nothing about vulnerabilities or malicious code in the source. Combine signature checks with provenance, scanning and a hardened build pipeline.

Should I use Rekor v2 in 2026?

For the public good instance you do not choose: it still defaults to Rekor v1, and the maintainers plan to keep it that way until the post-quantum transition. Current clients such as cosign v3 can verify v2 entries. Run v2 yourself only if you operate a private Sigstore deployment.

This quarter I would do three things, in order. Turn on trusted publishing for every package I publish and then remove the long-lived tokens, because an extra path is not a control. Sign every container image by digest in CI and attest the build provenance, which costs a few lines of YAML. Then, the step everyone skips, enforce verification with a pinned identity at the point of use: Kubernetes admission for images, npm audit signatures in CI for dependencies. The signing infrastructure is free and holds billions of entries; what is still missing in most organisations is the line of policy that says whose signature counts.

Related: CRA Reporting Went Live on 11 September, The Worms Learned to Use Your AI Agent and GitHub Actions Security in 2026.