Container Image Signing with Cosign: A Practical Verification and CI/CD Workflow

Overview

Image signing does not replace vulnerability scanning, SBOM generation, or access control. It answers a different question: Can this image be traced to an authorized signing identity or key, and has its signed reference been altered? A useful container security workflow combines signing with image scanning, provenance, an SBOM, least-privilege registry permissions, and deployment policy.

Cosign, from the Sigstore project, can sign container images and verify signatures. Teams can use a traditional private key or a keyless workflow based on an identity and an OIDC-backed certificate. Keyless signing can reduce the burden of distributing and rotating long-lived private keys, while key-based signing may fit environments with established key custody, offline signing, or existing compliance controls.

Before changing a production pipeline, confirm the Cosign version, registry behavior, CI identity provider, Kubernetes admission integration, and organization policy. Commands and flags can change between releases, so treat the examples below as a starting point and validate them in a non-production repository.

What to track

1. Sign immutable image references

Build and push an image using a digest rather than relying only on a mutable tag. A digest identifies the image content that the signer reviewed. A simplified workflow looks like this:

docker build -t registry.example.com/team/app:${GIT_SHA} .
docker push registry.example.com/team/app:${GIT_SHA}

docker inspect --format='{{index .RepoDigests 0}}' \
  registry.example.com/team/app:${GIT_SHA}

Capture the resulting reference in the pipeline. In practice, it will resemble registry.example.com/team/app@sha256:.... Sign and verify that digest, not an unpinned tag.

2. Choose a signing model

For a key-based workflow, generate or provision a key according to your organization’s secret-management policy, then keep the private key outside source control and ordinary build logs. A typical local signing pattern is:

cosign generate-key-pair
cosign sign --key cosign.key registry.example.com/team/app@sha256:IMAGE_DIGEST
cosign verify --key cosign.pub registry.example.com/team/app@sha256:IMAGE_DIGEST

Protect the private key with a secrets manager or a dedicated signing service. Do not place it directly in a repository or expose it as an unmasked pipeline variable.

In a keyless workflow, the CI job authenticates through an OIDC provider and Cosign obtains a short-lived signing certificate associated with that identity. The exact command depends on the configured Sigstore environment and CI provider. In an interactive environment, the general form is:

cosign sign registry.example.com/team/app@sha256:IMAGE_DIGEST
cosign verify \
  --certificate-identity=WORKLOAD_IDENTITY \
  --certificate-oidc-issuer=OIDC_ISSUER \
  registry.example.com/team/app@sha256:IMAGE_DIGEST

Use identity and issuer constraints during verification. Verifying only that “a signature exists” is weaker than verifying that the signature came from the expected repository, workflow, or service identity.

3. Confirm where signatures and evidence are stored

Cosign commonly stores signatures alongside the image in the registry, while keyless workflows can also record signing evidence in a Sigstore transparency log such as Rekor. Registry support, authentication, tag handling, and artifact retention policies matter. Test signing, pulling, garbage collection, replication, and verification after a registry migration.

Track the image digest, signer identity, certificate issuer where applicable, signing time, build or release identifier, and the transparency-log entry or bundle available to your workflow. These records make failed verification investigations more efficient.

4. Verify before deployment

A CI/CD pipeline should verify the exact digest that will be deployed. A basic gate should fail closed when verification fails, the signature is missing, the identity is unexpected, or the registry cannot return the required signature evidence. Keep scanning and SBOM checks as separate gates; signing alone does not establish that an image is free of vulnerabilities.

Tool and workflow comparison

Cadence and checkpoints

Review image-signing controls at release time, monthly or quarterly, and after changes to the build or deployment system.

• Every release: confirm the image is signed, the digest is pinned, and CI verifies the expected identity before promotion.
• Monthly: inspect failed verification events, unsigned-image exceptions, registry errors, and changes to CI workflow identities.
• Quarterly: test key backups or signing-service recovery, review keyless issuer and identity constraints, and verify that admission policies still match current namespaces and registries.
• After infrastructure changes: retest when migrating registries, changing CI providers, modifying repository names, upgrading Cosign, or changing Kubernetes admission components.

Keep a small inventory of signing keys, workload identities, trusted issuers, registries, admission policies, and owners. Link each production image to its build record and SBOM. This complements an software supply chain inventory rather than duplicating it.

How to interpret changes

A sudden increase in failed verification usually points to a workflow or identity change before it indicates an image compromise. Compare the failing digest with the signed digest, then check whether the registry contains the signature, whether the CI identity changed, and whether the verifier is applying stricter constraints than before.

If signatures disappear after replication or cleanup, review registry retention and artifact-association behavior. If verification fails after a repository rename, update identity policies deliberately rather than broadly trusting every identity from the CI provider. If a private key may have been exposed, stop using it, identify images signed with it, issue a replacement according to policy, and decide whether affected images must be rebuilt and redeployed.

For Kubernetes, admission enforcement should be introduced with an explicit exception process. Start by measuring which workloads would fail, then enforce for selected namespaces or environments. Document emergency bypasses, expiration dates, approvers, and the follow-up required to remove each exception. Pair this work with a broader Kubernetes deployment readiness review and, where applicable, your GitOps reconciliation process.

When to revisit

Use this checklist before each production release and schedule a deeper review at least quarterly:

1. Build and push the image, then record its immutable digest.
2. Sign the digest using the approved key-based or keyless workflow.
3. Verify the signature with the expected key, identity, and issuer constraints.
4. Confirm the CI pipeline promotes the same digest that was verified.
5. Check that the registry retains the image and its signature together.
6. Review Rekor or equivalent transparency evidence when the workflow provides it.
7. Apply Kubernetes admission enforcement or the documented temporary exception.
8. Record the result, signer, digest, policy version, and any exception owner.

Revisit this article when Cosign, Sigstore, your registry, CI provider, or Kubernetes admission tooling changes materially. Also return after a key rotation, registry migration, security incident, or new deployment path. A signing policy is effective only when it is tested against the way images are actually built, promoted, and run.