Sigstore in Image Registries: Adoption and Reality

In the last two years, Sigstore has moved from experimental project to de facto standard for OCI-artifact signing. Major registries added native support, upstream projects (Kubernetes, Jenkins, Node.js) sign their releases, and verification tooling is WORK IN PROGRESS. This article covers the real state of registry adoption in 2024, what works in production, and what’s still emerging.

Last Year’s Change

Concrete milestones:

Kubernetes signs all its images since 1.24 (2022) with cosign.
Python Package Index (PyPI) implements attestations with Sigstore (PEP 740, 2024).
NPM added provenance with Sigstore in Q4 2023.
Homebrew provenance in formulae.
Docker Hub beta of referenced artifacts (where Sigstore signatures live).

Direction is clear: signing as expected, not exception.

Adoption by Registry

Docker Hub

State: emerging support. Sigstore works via OCI artifacts (cosign uses it internally), but Docker Hub’s UI doesn’t prominently show signatures yet.

Use Sigstore with Docker Hub:

cosign sign docker.io/myuser/myapp:1.0
cosign verify docker.io/myuser/myapp:1.0 --certificate-identity=... --certificate-oidc-issuer=...

Works, but integration with Docker Scout and Docker Hub search is limited.

GitHub Container Registry (GHCR)

State: polished support. GitHub Actions natively integrates Sigstore via OIDC. Signing an image in workflow is practically one line:

- uses: sigstore/cosign-installer@v3
- run: cosign sign --yes ghcr.io/owner/repo:${{ github.sha }}

The workflow’s OIDC token links signature to workflow + repo + actor. Verifiable by anyone.

Strong adoption among OSS projects publishing to GHCR.

AWS Elastic Container Registry (ECR)

State: support via OCI artifacts, but no ECR-native integration (yet). Plugins and scripts exist but not first-class.

AWS has its own ECR image signing based on AWS KMS, alternative to Sigstore. Both coexist. Some enterprises use Sigstore keyless, others KMS native signing.

Google Artifact Registry (GAR)

State: integration with Binary Authorization (GCP-native) and Sigstore. Good experience in GCP-native workflows.

Google also has integrated SLSA attestations, can be Sigstore-signed.

Harbor

State: Notary v2 / Sigstore natively supported from Harbor 2.5+.

Harbor is the most advanced open-source registry for signing. Can:

Store Sigstore signatures.
Enforce signing policies on specific projects.
Integrate with public or private Fulcio/Rekor.
Expose signing state in UI.

For self-hosted organisations, Harbor + Sigstore is a mature setup.

Quay (Red Hat)

State: mature Sigstore support. Enforceable signing policy. Good OpenShift integration.

Verification Flows

Three production patterns:

In Admission Controller

Kyverno with Sigstore rule:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: verify-sigstore
spec:
  validationFailureAction: enforce
  rules:
    - name: check-signatures
      match:
        resources:
          kinds: [Pod]
      verifyImages:
        - imageReferences:
            - "ghcr.io/myorg/*"
          attestors:
            - entries:
                - keyless:
                    identities:
                      - issuer: https://token.actions.githubusercontent.com
                        subject: https://github.com/myorg/*

Pods with unsigned or wrongly-signed images are rejected.

In GitOps (Flux/Argo)

Flux 2 supports Sigstore verify in its Kustomization:

apiVersion: image.toolkit.fluxcd.io/v1beta2
kind: ImagePolicy
metadata:
  name: myapp
spec:
  imageRepositoryRef:
    name: myapp-repo
  policy:
    semver:
      range: ">=1.0.0"
  verify:
    provider: cosign
    secretRef:
      name: cosign-public-key

If signature doesn’t verify, Flux doesn’t reconcile.

In CI/CD Pipeline

Verify before deploy:

cosign verify $IMAGE \
  --certificate-identity-regexp='^https://github.com/myorg/.+$' \
  --certificate-oidc-issuer=https://token.actions.githubusercontent.com \
|| { echo "INVALID SIGNATURE"; exit 1; }

deploy-script $IMAGE

Signed Provenance and SBOM

Beyond the image itself, the ecosystem is signing provenance and SBOM:

SLSA provenance: who, how, when built the image. Sigstore-signable.
SBOM: dependency inventory. Signable.
Attestations: specific assertions (tests passed, vuln scan clean).

Tools:

oras: CLI for OCI artifacts.
cosign attest: attach signed attestations.
chainguard-images: pre-signed images with SBOMs.

Current Challenges

Honest about what doesn’t work perfectly yet:

Public Rekor limits: public Rekor has rate limits; large enterprises need their own.
Key distribution: verifying signature requires knowing which identities to accept. Governance needed.
Identity rotation: if CI identity changes, verification may break.
Legacy registries: some old registries don’t support OCI artifacts.
Binary authorisation vs Sigstore: some ecosystems have their own mechanisms.

The Debate: Keyless vs KMS

Sigstore keyless relies on public Fulcio. Alternatives:

KMS signing: key in AWS KMS, GCP KMS, HashiCorp Vault. Not Fulcio-dependent.
Static keypair: locally-generated key, company-managed.

For regulated enterprises, KMS tends to be preferred. For most, keyless is simpler.

Real Cases

Chainguard: all images signed, SBOMs attached.
Distroless: Google-signed.
Alpine Linux: exploring signatures.
Anthos: policy enforcement with signatures.

The Horizon: Trusted Supply Chain

Beyond signing an image, direction is:

Complete build provenance (SLSA L3+).
Reproducible builds where possible.
Policy as code about acceptable identities and processes.
Supply-chain observability: visibility of what reaches production.

Sigstore is foundational piece. Full building still under construction.

Practical Recommendations

For an enterprise adopting today:

Sign with cosign keyless in CI if using GitHub/GitLab/Gitea.
Choose a supporting registry: GHCR for GitHub-native, Harbor for self-hosted.
Admission verification with Kyverno or Gatekeeper.
Document accepted identities in Git (as policy).
Alert on unsigned images in production.
Review identity rotation annually.

Conclusion

Sigstore in image registries has moved from proposal to operable reality. GHCR, Harbor, Quay have polished support; Docker Hub, ECR, GAR are adopting. The policy of “only deploy signed images from known identities” is feasible today, not a distant future. For enterprises serious about supply-chain security, not implementing it in 2024 is a deliberate omission. Tooling exists; learning curve is manageable; ecosystem moves this direction.