Skip to main content
Articlesupply chain security

Sigstore and Cosign: Verify Container Images

Sign and verify container images with Cosign, keyless identities, transparency evidence, digest pinning, and admission policies that check the signer.

IsMalicious TeamIsMalicious Team
3 min read
Cover Image for Sigstore and Cosign: Verify Container Images
Signal
Context
Action

Container tags are convenient labels, not immutable identities. If a registry tag moves or an image is replaced, a deployment may run content that reviewers never approved. Sigstore and Cosign help sign and verify artifacts by digest and signer identity.

The critical word is “verify.” Signing everything without a policy that checks the expected source, workflow and identity does not stop an untrusted signer.

What Cosign Adds

Cosign supports key-based and keyless signing, signatures attached to container images, attestations and transparency evidence. The Sigstore verification documentation shows that identity-based verification checks both certificate identity and OIDC issuer.

A useful verification answers:

  • does the signature validate?
  • does it bind to this exact image digest?
  • who signed it, under which issuer?
  • is that identity approved for this repository and environment?
  • does required provenance or attestation exist?

Cryptographic validity is necessary but not sufficient. Trust comes from matching the result to expectations.

Keyless Signing and Identity

In a keyless flow, a workload obtains a short-lived signing certificate after authenticating through an OIDC identity provider. This reduces long-lived private-key handling, but it shifts attention to workflow identity and issuer claims.

Constrain trust to the expected repository, workflow, branch or release environment. A policy that accepts any certificate from a large public issuer is too broad.

Protect the CI workflow itself:

  • require review for workflow changes;
  • pin third-party actions;
  • isolate untrusted pull requests;
  • grant the minimum token permissions;
  • separate build, sign and deploy responsibilities;
  • keep runners ephemeral where possible.

Sign the Digest, Deploy the Digest

Build once, calculate the digest, generate provenance and SBOM, sign the immutable artifact, and promote that same digest. Do not rebuild independently for each environment and assume the outputs match.

At verification time, check signature and claims against policy. At deployment time, reference the digest rather than a mutable tag. Store the verified signer and provenance result in deployment logs.

Admission Policy in Kubernetes

An admission controller can reject images that are unsigned, signed by an unexpected identity or missing required attestations. Roll out carefully:

  1. inventory current images and registries;
  2. define trusted identities per namespace or workload;
  3. run in audit mode;
  4. fix legitimate exceptions;
  5. enforce for high-value environments;
  6. expire temporary bypasses.

Keep a break-glass procedure that is authenticated, logged, time-limited and reviewed. A permanent “skip verification” label defeats the control.

Signatures, Provenance and Vulnerabilities

Signatures prove integrity and identity. SLSA provenance describes the build. An SBOM lists components. Vulnerability intelligence tells you which components carry known risk. Runtime security watches what the deployed workload does.

A correctly signed malicious build remains malicious. Combine the controls rather than promoting signing as a safety certificate.

Check suspicious image layers with file hash reputation and investigate their domains and IPs if runtime telemetry shows unexpected communication.

Incident Response

When verification fails, stop promotion and preserve image digest, signature bundle, certificate, issuer claims, registry events and CI logs. Determine whether the image changed, the signer was unexpected, policy drifted or the workflow was compromised.

Search for every deployment of the digest and other artifacts signed by the suspect identity. Revoke or constrain trust at the policy layer and rebuild only from a known-good source.

Metrics

Track images deployed by digest, verified signatures, identity-policy failures, unsigned exceptions, time to trace a digest to a workflow and deployments rejected before runtime. Measure stale bypasses as a security debt.

Conclusion

Cosign makes image identity verifiable; policy makes that verification meaningful. Bind signatures to immutable digests and expected CI identities, then enforce at registry and admission boundaries. Pair container security with provenance, SBOM and runtime evidence for end-to-end supply-chain control.

FAQ

Frequently asked questions

What does Cosign verify for a container image?
Cosign can verify that a signature is valid, binds to the image digest, and matches an expected key or certificate identity and OIDC issuer. Policy must define which identities are trusted.
Does a signed container image mean it is safe?
No. A signature proves integrity and signer identity under a trust policy. It does not prove the code is non-malicious or free of vulnerabilities.
Why should deployments use image digests instead of tags?
Tags can move to a different image. A digest immutably identifies content, allowing the verifier, admission policy, SBOM, provenance, and runtime inventory to refer to the same artifact.
Read next

Protect Your Infrastructure

Check any IP or domain against our threat intelligence database with indexed records.

Try the IP / Domain Checker