What Is Container (Docker) Image Signing?

Container image signing is the practice of attaching a cryptographic signature to a container image so that anyone pulling it can verify who published it and confirm it has not been altered since it was built. It is code signing applied to the OCI images that run in Docker and Kubernetes.

Container image signing attaches a digital signature to a Docker or OCI image, tied to the image’s content digest, so a registry or Kubernetes cluster can verify the image’s origin and integrity before running it. Signing proves the image came from your build pipeline and was not tampered with in the registry or in transit. The common tools are Sigstore Cosign and Notary v2 (Notation), which store signatures as separate artifacts in the registry alongside the image.

Key Takeaways

• Container image signing attaches a cryptographic signature to a container image, tied to its content digest, so consumers can verify who built it and that it has not been modified.
• Modern signing does not embed the signature inside the image. The signature is stored as a separate artifact in the OCI registry that references the image digest.
• The main tools are Sigstore Cosign (developer-friendly, supports keyless OIDC signing and key-based signing) and Notary v2 / Notation (standardized, PKI and trust-store oriented, favored for enterprise). Docker Content Trust (DCT) is the older approach and is being retired for Docker Official Images.
• Always sign the image digest (the @sha256 reference), never a mutable tag such as :latest, because tags can be repointed to different content.
• Verification is enforced at deployment through Kubernetes admission controllers, so unsigned or untrusted images are blocked before they run.

Why Container Image Signing Matters

Containers are the standard unit of modern software deployment, and a container image passes through many hands between build and runtime: a CI system builds it, a registry stores it, an orchestrator pulls it, and a node runs it. At any of those points, an attacker who can substitute or modify an image can run their code inside your environment. Container image signing closes that gap by making tampering detectable.

This is the same supply-chain problem that made the SolarWinds attack so damaging, applied to containers. A signature proves two things a registry alone cannot: provenance, meaning the image genuinely came from your pipeline, and integrity, meaning the exact bytes you signed are the exact bytes being run. Without signing, a registry only tells you an image exists, not that it is the one you trust.

How Container Image Signing Works

Container signing follows the same public-key pattern as any code signing, adapted to the way container registries store data.

1. Build and push by digest: Your pipeline builds the image and pushes it to a registry. The image is identified by an immutable content digest (a sha256 hash of its contents), not only by a mutable tag.
2. Sign the digest: A signing tool hashes the image manifest and signs it with a private key, producing a signature bound to that exact digest. Signing the digest, not the tag, is essential, because tags can later be repointed to different content.
3. Store the signature in the registry: The signature is uploaded to the same registry as a separate OCI artifact that references the image digest. The signature lives alongside the image rather than inside it.
4. Verify before running: At deployment, a verifier fetches the signature, checks it against the trusted public key or identity, and confirms the digest matches. If verification fails, the image is rejected.

A crucial detail: because the signature is bound to the digest, it protects the exact image content. If even one byte of the image changes, the digest changes, and the signature no longer matches. This is what makes tampering detectable.

The Main Container Signing Tools

Three approaches dominate, and knowing which is which prevents a lot of confusion.

Sigstore Cosign

Cosign, part of the Linux Foundation’s Sigstore project, is the most widely adopted container signing tool. It supports two modes. Key-based signing uses a private key you manage, which can live in a file, a cloud KMS, or an HSM accessed over PKCS#11.

Keyless signing uses short-lived certificates issued by Sigstore’s Fulcio certificate authority based on an OIDC identity (such as a GitHub, Google, or Microsoft account), with the signing event recorded in the Rekor public transparency log. Cosign stores signatures in the OCI registry alongside the image and integrates cleanly with CI systems and Kubernetes admission control.

Notary v2 (Notation)

Notation is the CLI for Notary v2, a CNCF project. It emphasizes a standardized signature format and a PKI and trust-store model, where administrators define which signing identities are trusted through a trust policy. This design appeals to enterprises that already run their own certificate authorities and want vendor-supported, specification-driven signing. Notation is recommended in the managed Kubernetes guidance from Microsoft (AKS) and Amazon (EKS).

Docker Content Trust (legacy)

Docker Content Trust (DCT), built on The Update Framework and released in 2015, became the Notary v1 project. It is the original container signing mechanism, but it is now legacy. Docker has stated it is retiring DCT for Docker Official Images and advises publishers to migrate to a newer system such as Sigstore or Notation. Registry platforms are following suit; for example, Harbor deprecated Notary v1 support in version 2.9 and uses Cosign or Notation instead. New deployments should not standardize on DCT.

Tool	Trust model	Best fit
Cosign (Sigstore)	Keyless OIDC via Fulcio and Rekor, or self-managed keys	Developer-friendly signing, CI/CD, open source, broad registry support
Notation (Notary v2)	PKI and trust store, standardized signature format	Enterprises with existing PKI; AKS and EKS guidance
Docker Content Trust (Notary v1)	TUF-based, per-tag keys	Legacy only; being retired, plan migration

Best Practices for Container Image Signing

• Sign the digest, not the tag: Bind signatures to the immutable sha256 digest. A tag like :latest can be repointed to different content, so signing a tag proves almost nothing.
• Protect signing keys in hardware: Long-lived signing keys should live in an HSM or a hardware-backed KMS, not on a developer laptop or a CI runner’s disk, so a compromised build host cannot steal them.
• Enforce verification at admission: Use a Kubernetes admission controller or policy engine to block unsigned or untrusted images at deploy time, so signing is not merely advisory.
• Verify identity, not just presence: Check that an image is signed by an identity you trust, not merely that some signature exists. A signature from an unknown key is not trust.
• Attach provenance and SBOMs: Modern tooling can attach build provenance attestations and a Software Bill of Materials to the same digest, strengthening the chain of custody.
• Centralize keys and audit: Use a central signing service so every signing operation is authenticated, logged, and auditable, rather than scattered across teams with their own keys.

The Enterprise Gap: Key Management

The signing tools solve the mechanics of producing and verifying a signature. They do not, on their own, solve enterprise key management. In practice, that is where container signing programs succeed or fail.

If signing keys sit on developer machines or CI runners, they are exposed to exactly the supply-chain compromise that signing is meant to prevent. If every team manages its own keys, there is no central audit trail of who signed what, no consistent policy, and no easy way to rotate or revoke keys after an incident. Keyless signing shifts the trust to an identity provider and a public transparency log, which suits open-source projects but does not fit every enterprise’s compliance and privacy needs.

The enterprise requirement is to keep container signing keys in hardware, enforce who may sign, and log every operation, without slowing developers down.

How Encryption Consulting Helps

Encryption Consulting’s CodeSign Secure brings enterprise key management to container image signing. It keeps signing keys in a FIPS 140-2 Level 2 HSM rather than on developer machines or CI runners, integrates with the container signing workflow so images are signed against hardware-protected keys, and enforces who is allowed to sign while logging every operation for audit.

Because CodeSign Secure centralizes signing across artifact types, the same platform that protects your Windows, Java, and firmware signing also governs your container images, giving security teams one consistent policy and audit trail rather than a separate, ungoverned process for containers. Backed by ISO/IEC 27001:2022 and SOC 2 certified practices.

Frequently Asked Questions

What is container image signing?

Container image signing attaches a cryptographic signature to a container (OCI) image so that anyone pulling it can verify who published it and confirm it has not been altered since it was built. The signature is bound to the image’s content digest and stored in the registry as a separate artifact. It is the container-world equivalent of code signing, and it protects the software supply chain between build and deployment.

What is the difference between Cosign, Notation, and Docker Content Trust?

Cosign, part of Sigstore, is a developer-friendly tool supporting both keyless OIDC signing and self-managed keys, and is widely used in CI/CD. Notation, the CLI for Notary v2, is a CNCF project with a standardized signature format and a PKI trust-store model favored by enterprises and recommended for AKS and EKS. Docker Content Trust (Notary v1) is the original, TUF-based mechanism from 2015; it is now legacy and being retired for Docker Official Images.

Should I sign the image tag or the digest?

Always sign the digest, the immutable @sha256 reference, never a mutable tag like :latest. Tags are pointers that can be repointed to different content at any time, so a signature on a tag proves almost nothing about what actually runs. A signature bound to the digest protects the exact image bytes: if any byte changes, the digest changes and the signature no longer verifies, which is what makes tampering detectable.

Is Docker Content Trust still recommended?

No. Docker Content Trust (DCT), based on Notary v1, is legacy. Docker has stated it is retiring DCT for Docker Official Images and advises publishers to move to a newer signing and verification solution such as Sigstore or Notation. Registry platforms are following the same path; for example, Harbor deprecated Notary v1 in version 2.9. Existing DCT users should plan a migration, and new deployments should standardize on Cosign or Notation instead.

How is a signed container image verified at deployment?

Verification is typically enforced by a Kubernetes admission controller or policy engine that intercepts image deployments. When a pod is scheduled, the controller fetches the image’s signature from the registry, checks it against the trusted public key or identity, and confirms the signature matches the image digest. If the image is unsigned or signed by an untrusted identity, the controller rejects it, so only verified images ever run in the cluster.

Where should container signing keys be stored?

Long-lived container signing keys should be stored in a Hardware Security Module (HSM) or a hardware-backed key management service, not on developer laptops or CI runner disks, which are exactly the systems an attacker would target. Storing keys in hardware means a compromised build host cannot exfiltrate the private key. Enterprises typically use a centralized signing service that keeps keys in an HSM, enforces who may sign, and produces an audit log of every signing operation.

Bring Enterprise Key Management to Your Container Signing

Signing tools produce signatures. Enterprise programs need those signatures backed by hardware-protected keys, enforced policy, and a full audit trail. Explore CodeSign Secure to sign your container images against HSM-protected keys with centralized policy and audit, alongside the rest of your code signing.