Sigstore in Image Registries: Adoption and Reality

Actualizado: 2026-05-03

In barely two years, Sigstore^[1] has moved from academic curiosity to an assumed piece of the software supply chain. What makes the current moment interesting is not that the technology exists — which was already true in 2022 — but that the registries where images actually live have finally accepted it as a first-class citizen. The tonal shift is what matters: until recently, signing an image was a political statement inside a team; today it looks more like enabling HTTPS on a fresh server.

Key takeaways

• Kubernetes has been signing all its images since 1.24; PyPI, npm, and Homebrew have adopted Sigstore for provenance.
• GHCR is the best-integrated registry: GitHub Actions issues OIDC tokens that cosign sign --yes consumes without friction.
• Harbor 2.5+ and Quay offer native support; AWS ECR is the least friendly and pushes its own KMS scheme.
• Verification earns its keep at three points: cluster admission controller, GitOps layer, and CI/CD pipeline.
• The public Rekor has rate limits that fall short for intensive builds; past a certain volume, a private Rekor is needed.

What Changed in the Last Year

The tipping point is the accumulation of signals:

• Kubernetes signs all its images since 1.24 — precedent copied across much of the CNCF ecosystem.
• PyPI published PEP 740, pushing Sigstore-backed attestations for Python packages.
• npm added provenance in late 2023 on the same infrastructure.
• Homebrew started attaching provenance to its formulae.
• Docker Hub now serves referenced artifacts in beta.

Read together, signing has stopped being an exception and become the default state any mature pipeline is expected to produce.

Registry by Registry

GHCR is the best-integrated registry. GitHub Actions issues an OIDC token identifying the workflow, repository, and actor, and cosign sign --yes consumes it without friction. The signature ends up bound to a verifiable identifier in Rekor’s transparency log without managing local keys. For open-source projects publishing to GHCR, adoption is already the majority.

Harbor has done its homework on the self-hosted side. Since version 2.5 it natively supports Sigstore signatures, allows enforcement policies per project, can point at private Fulcio and Rekor, and reflects signing state in the UI. Adding verification is not a rewrite — it’s a checkbox.

Quay (Red Hat) offers comparably mature support. Google Artifact Registry fits with Binary Authorization and accepts Sigstore-signed SLSA attestations. AWS ECR is the awkward one: supports Sigstore via OCI artifacts but has no UI or first-class integration. Docker Hub has the plumbing but not the UX.

Verifying Without Overbuilding

The interesting part is not signing, it is verifying in a way that turns the signature into a real gate. Three places where verification earns its keep:

Admission controller: Kyverno expresses a policy declaring accepted identities. A Pod trying to start from an unsigned image, or one signed by an identity outside the policy, is rejected before the scheduler sees it.

GitOps layer: Flux 2 allows an ImagePolicy demanding cosign verification that blocks reconciliation if the signature doesn’t match.

Pipeline: a pre-deploy step running cosign verify:

cosign verify "$IMAGE" 
  --certificate-identity-regexp='^https://github.com/myorg/.+$' 
  --certificate-oidc-issuer=https://token.actions.githubusercontent.com

What matters is not the command but the contract behind it: only images produced by workflows inside our organisation pass.

Provenance, SBOM, and Attestations

Signing the digest is level one. The next level is signing attestations about that digest: who built the image, with which builder, from which commit, which tests ran, which vulnerabilities the scanner found. cosign attest attaches those documents under the same identity model, and the consumer can demand “is it signed and does it carry a SLSA v1.0 provenance matching this repo”.

Real Limits Worth Acknowledging

• The public Rekor has rate limits that suffice for small projects but fall short for intensive builds.
• Identity distribution is a governance problem: verification requires maintaining which issuers and subjects are legitimate.
• Rotating CI identities can break verification until policies are updated.
• In regulated environments, Sigstore keyless on public Fulcio may not fit custody procedures.

Conclusion

For an organisation starting today, the sensible path is to sign keyless with cosign from CI workflows, publish to GHCR or self-hosted Harbor, enforce verification in admission with Kyverno, document accepted identities in the repository as versioned policy, and alert on unsigned images reaching production. Sigstore does not solve supply chain security on its own: it solves the link “this image was produced by this process at this moment”. But that link is no longer debatable: signing OCI artifacts is now normal, and choosing not to is starting to require an explanation.

1. Sigstore