Container Image Signing: Security, Verification & Best Practices

Key Takeaways

• Container image signing lets you automatically verify that an image hasn’t been tampered with and was signed by an approved identity before it runs.
  
• Signing proves integrity and authenticity, but it doesn’t guarantee the image is free of vulnerabilities, so it should be combined with scanning, attestations, and runtime monitoring.
  
• Real protection comes from enforcing verification in CI/CD and Kubernetes admission controls, especially by signing immutable digests instead of mutable tags.
  
• Your trust model (central key, keyless OIDC, or private PKI) determines how sustainable and secure your signing program will be in production.
  
• Even with signed images, you still need runtime visibility to detect suspicious behavior after deployment, since signing only protects what you deploy, not what the container does once running.

Container image signing matters because it turns “trust” into something you can verify automatically before an image runs. In Sonatype’s 2024 State of the Software Supply Chain report, the company reports a 156% year-over-year increase in malicious packages, which is a big reason security teams now treat supply chain controls as a baseline requirement rather than “nice to have.”

Image signing does two things well. It lets you verify that the image you’re about to run matches a signed digest (integrity), and it lets you define which identities are allowed to sign approved images (authenticity). It does not, by itself, guarantee the software inside the container is safe, so it works best when paired with scanning, attestations, and runtime monitoring.

This article explains how container image signing works in real-world pipelines, how to make sure that signatures are checked in Kubernetes, and how to create trust models that will last in

production environments. You will also learn how signing works with supply chain security controls and runtime monitoring to lower the risk of software integrity from start to finish.

What Is Container Image Signing?

Container image signing is the act of generating an image signature over an immutable image reference, usually the digest, and publishing that signature so others can perform signature verification before deployment. The practical goal is simple: if someone swaps, tampers with, or impersonates your container image, verification fails, and your enforcement point (CI/promotion gates or Kubernetes admission policies) can block the deploy.

A common approach is to store the signature in the same OCI registry as a related artifact, which keeps distribution simple. For example, the cosign README describes how cosign supports signing, verifying, and storing signatures in OCI registries.

Image Signing vs. Code Signing

Code signing typically targets binaries or packages. Image signing targets the container image as the deployable artifact, including filesystem layers and metadata, and is usually enforced earlier in delivery and again at deploy time.

In other words, code signing is often verified by endpoints and operating systems, while image signing is commonly enforced by CI/CD gates and Kubernetes admission controls.

How Container Image Signing Works in Practice

A realistic signing workflow is a loop that repeats across environments.

1. Build the container image.
   
2. Push it to a container registry.
   
3. Sign the image digest.
   
4. Verify the signature wherever the image is promoted or deployed.
   
5. Block anything that does not verify.

The key operational detail is digest discipline. Tags are convenient but mutable, so teams that only “trust tags” leave a gap for later tag moves, which is why Kyverno documents mutateDigest and verifyDigest in its verifyImages rule to convert tags to digests and enforce digest usage during admission.

Core Components of Container Image Signing

Container image signing works when you can answer three questions consistently: who is allowed to sign, where the signature is stored, and where verification is enforced. The components below map directly to those three requirements:

1. A Signer Identity or Private Key

Every image signing system has a “who is allowed to sign” component.

• A traditional model uses a long-lived private key and a public key for verification.
  
• A keyless model uses short-lived credentials and an identity provider, so the signature is bound to an identity rather than a distributed private key.

Cosign supports multiple models, including keyless signing and KMS-backed signing, as described in the cosign README.

2. A Signature Format and Storage

With modern OCI registries, signatures are often stored as separate OCI objects related to the image digest. The cosign README explains that signatures are stored as separate objects in the OCI registry with a reference back to what they sign, which is important for retention and portability.

3. A Verifier and an Enforcement Point

Verification can be done in several places, and this is where “image verification” becomes a real control.

• CI and promotion gates, so unsigned images don’t move to staging or prod.
  
• Kubernetes admission controllers, where pods referencing untrusted images are rejected.
  

Registry policies depend on your registry ecosystem.

If you want Kubernetes to enforce signed images at deploy time, Kyverno documents admission-time verification with its verifyImages rule.

Container Image Signing Tools

These are common tools teams use to implement signing end-to-end, from creating signatures in CI to storing them alongside images, and enforcing verification at promotion or Kubernetes admission time:

Sigstore Cosign

Cosign is a Sigstore tool for creating and verifying image signatures and for storing them in OCI registries. The upstream cosign README also lays out supported modes like keyless signing, KMS signing, and bring-your-own PKI. If you want the conceptual picture behind keyless signing, Sigstore’s docs include a cosign signing overview that explains the identity-based approach and the role of Sigstore services.

Kyverno Image Verification

Kyverno can verify container images at admission time using its verifyImages rule, including options for required verification and digest enforcement, and it documents attestor configuration patterns used to control which keys or identities are trusted.

Notary Project Notation

The Notary Project’s notation repository describes Notation as a CLI tool used to sign and verify artifacts.

How to Implement and Operationalize Container Image Signing

A successful rollout moves from ad-hoc signing to automated enforcement. This table outlines a phased approach to operationalize signing without breaking deployments.

The phased rollout above provides the operational model. The sections below break down the most critical implementation layers in more detail, focusing on CI integration, registry storage, and Kubernetes admission enforcement. Together, these form the core control points for container image signing in production environments.

Implement Container Image Signing in CI/CD Pipelines

Start by signing the digest immediately after pushing the image, and verify again during promotion. This keeps signing identities and signing keys inside controlled automation rather than on developer laptops.

Build and push, capture the digest

IMAGE="ghcr.io/acme/api"
TAG="1.2.3"

docker build -t "${IMAGE}:${TAG}" .
docker push "${IMAGE}:${TAG}"

DIGEST="$(docker inspect --format='{{index .RepoDigests 0}}' "${IMAGE}:${TAG}")"
echo "Digest: ${DIGEST}"

Sign the image digest with cosign

cosign sign --key cosign.key "${DIGEST}"

If you want to avoid managing long-lived private keys in CI, keyless signing can be a better fit. GitLab includes practical CI patterns in its guide on using Sigstore for keyless signing and verification.

Store and Distribute Container Image Signatures in OCI Registries

A common failure mode is treating signatures like external metadata that lives somewhere else. Storing signatures in the registry makes verification easier for clusters and downstream environments and reduces “can’t fetch signature” friction. Because cosign stores signatures as OCI objects in the registry, your retention policies should account for signature artifacts as well as images, which is described in the cosign README’s registry details.

Verify Container Images in Kubernetes Using Admission Controls

This is where most teams get real value, because verifying container images becomes mandatory rather than optional. Kyverno’s verifyImages policy documentation describes how to require verification, mutate tags to digests, and enforce digest usage.

Example Kyverno policy to require signed images

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: verify-signed-images
spec:
  validationFailureAction: Enforce
  background: false
  rules:
    - name: require-signed-images
      match:
        any:
          - resources:
              kinds:
                - Pod
      verifyImages:
        - imageReferences:
            - "ghcr.io/acme/*"
          required: true
          mutateDigest: true
          verifyDigest: true
          attestors:
            - entries:
                - key:
                    publicKeys: |-
                      -----BEGIN PUBLIC KEY-----
                      REPLACE_WITH_YOUR_PUBLIC_KEY
                      -----END PUBLIC KEY-----

This does three important things. It requires a signature, it reduces tag-based drift by mutating to digests, and it enforces that the workload ultimately runs pinned digests rather than mutable tags, which is exactly the behavior described in Kyverno’s verifyImages guidance.

Trust Models and Key Management in Container Image Signing

The trust model behind container image signing is what makes it work. How you issue, store, and verify signing identities will determine whether your program is operationally sustainable or a long-term key management headache. The table below shows how the most common trust models used in production environments compare to each other.

When set up correctly, each model can support signing container images safely. Smaller teams usually start with a centralized key stored in KMS. On the other hand, bigger companies are more and more choosing keyless signing to lower the risk of managing keys. In highly regulated environments, a private PKI may be needed to follow internal compliance rules.

Challenges and Limitations of Container Image Signing in Production

These limitations are the gaps teams hit when they move from “we can sign images” to “we can enforce and operate signing reliably across teams, registries, and environments”:

• Signed Does Not Mean Secure: Image signing is an integrity and provenance control, not a vulnerability fix. If you sign a vulnerable image, it still verifies.
  
• Trust Policy Drift: Keyless signing improves key hygiene but increases policy surface area. Workflows change, repositories move, and branch protections evolve. If your trust policy is too strict, you block releases. If it is too loose, you allow unexpected signers.
  
• Tag-Based Loopholes: If you verify signatures but still deploy mutable tags, you leave room for tag moves after verification, which is why Kyverno emphasizes digest-related enforcement options in its verifyImages documentation.
  
• Retention and Garbage Collection: Because signatures may be stored as separate OCI objects, you need deliberate lifecycle management so signatures remain available for verification. Cosign’s “Registry Details” section in the cosign README is the best reference for how signature objects behave relative to image deletion.

Best Practices for Secure Container Image Signing at Scale

Operating signing at scale requires treating it as a standard platform capability, not just a security checklist item.

Runtime Visibility and Integrity Monitoring for Signed Container Images with groundcover

Image signing helps ensure the artifact you deploy is the one you intended. Runtime monitoring helps you catch what happens after deployment, including unexpected process execution, suspicious network access, or drift from normal behavior.

If you want to connect signed images to runtime integrity signals, groundcover’s overview of Kubernetes runtime security is a useful place to anchor what “runtime” checks look like in real clusters. If you prefer a lower-overhead collection approach for investigating behavior changes, groundcover’s explainer on eBPF in Kubernetes describes how kernel-level signals can be correlated with Kubernetes context.

Traditional observability often relies on sidecars or code instrumentation, which can be bypassed or tampered with. groundcover uses eBPF to collect signals directly from the Linux kernel, enabling deep visibility into network flows and process activity without requiring application changes. Furthermore, its BYOC deployment model ensures that your sensitive telemetry data never leaves your cloud perimeter, satisfying the strictest data sovereignty requirements of a secure software supply chain.

Conclusion

Container image signing is a high-leverage control for software supply chain security because it makes provenance and integrity verifiable and enforceable. You get the most value when you sign immutable digests, store signatures in your OCI registry, and enforce verification at promotion and admission using tools like cosign (as described in the cosign README) and policies like Kyverno’s verifyImages rule.