Signing docker images means attaching a cryptographic signature to an image manifest so that anyone pulling it — a Kubernetes cluster, a CI runner, another engineer — can verify the image came from a trusted source and hasn't been altered since it was built. A registry can tell you an image exists and hasn't been corrupted in transit (via its content digest), but it can't tell you who built it or whether it's the exact artifact your pipeline produced. Signing closes that gap, and it's why image signing has moved from a niche compliance checkbox to a default expectation in supply-chain-security frameworks like SLSA and in software delivered to government and regulated customers.
Why isn't a registry digest enough on its own?
A registry digest — the sha256: hash every image already has — only proves the bytes you pulled match the bytes that were pushed under that digest; it says nothing about who pushed them or whether the push was authorized. Anyone with write access to a registry, or anyone who compromises a CI credential, can push a malicious image under a tag your deployment pipeline trusts, and the digest will still be internally consistent — it just won't match what your actual build process produced. Signing adds an independent, cryptographically verifiable claim: "this specific artifact was produced and attested to by this specific identity," which a compromised registry push alone can't fake without also compromising the signing key or identity.
What is Cosign and how does image signing work with it?
Cosign is an open source tool from the Sigstore project (originally built by the container security community and now a CNCF project) that signs and verifies container images and other OCI artifacts. Cosign supports two signing models: a traditional key pair you generate and manage yourself, and "keyless" signing, where Cosign issues a short-lived certificate tied to an OIDC identity — such as a GitHub Actions workflow identity — instead of a long-lived private key you have to store and rotate. The signature itself is stored either alongside the image in the OCI registry as a separate artifact, or in a public transparency log (Sigstore's Rekor), so that a signature's existence and timing are independently auditable rather than resting solely on trust in the signer.
Keyless signing in particular addresses a real operational problem: long-lived signing keys are themselves a high-value target and a rotation headache, and a leaked signing key undermines every signature it ever produced. Tying signatures to short-lived, workflow-scoped OIDC credentials narrows that blast radius considerably — a compromised key doesn't exist for an attacker to steal in the first place.
What is Notary and how does it differ from Cosign?
Notary is the reference implementation of The Update Framework (TUF), a signing specification originally developed at NYU and adopted by the CNCF, and it predates Cosign as a container-signing approach — Docker Content Trust, Docker's built-in signing feature, is built on an earlier version of Notary. Notary v2 (also known as containerd's image-spec signing work, converging with the broader OCI signing effort) generalized the approach beyond Docker's original implementation to work across registries more broadly. The practical difference most teams care about is ecosystem fit: Cosign integrates tightly with the broader Sigstore toolchain (Rekor for transparency logging, Fulcio for keyless certificate issuance) and has become the more common default in Kubernetes-native tooling, while Notary/TUF's design emphasizes a more formal, role-separated trust delegation model that some enterprise and regulated environments still standardize on.
Both tools solve the same fundamental problem — binding a verifiable identity to an image artifact — and both integrate with policy enforcement at deploy time, so the meaningful question for most teams isn't "which is theoretically better" but "which does our registry and orchestration platform already support well."
How do you actually enforce signature verification in a pipeline?
Signing an image only produces security value if something downstream refuses to run unsigned or improperly signed images — otherwise it's a nice-to-have that gets checked in a dashboard and ignored operationally. In Kubernetes, admission controllers like Kyverno or Connaisseur can be configured to reject pod creation for any image lacking a valid Cosign signature from an approved identity, turning signing from advisory into a hard gate. In CI/CD, the equivalent control is a pipeline step that verifies a signature before promoting an image from a staging registry to production, failing the deployment if verification fails rather than just logging a warning.
A common rollout mistake is signing images without ever configuring verification, which delivers process overhead without the actual security benefit — teams sign because a checklist says to, but nothing downstream checks, so a compromised or unsigned image still deploys unimpeded. Treat signing and verification as one control, not two independent projects, and roll out verification in "warn" mode before flipping it to "block" so you can find and fix legitimate images that fail verification (often due to a misconfigured signing step) before it becomes a production outage.
How Safeguard Helps
Safeguard's container scanning inventories every image in your registries and pipelines and flags images that lack a valid signature or that were signed by an identity outside your approved list, giving policy teams visibility into signing coverage across the fleet rather than a single pipeline. Combined with vulnerability and SBOM data on the same image, that lets teams prioritize enforcement — for instance, requiring signatures first on internet-facing production images before extending the requirement to internal tooling. See the container security capabilities under SCA for how image provenance data feeds into broader supply-chain risk scoring.
FAQ
Do I need Cosign, Notary, or both?
Most teams pick one based on ecosystem fit rather than running both — Cosign's tighter integration with Kubernetes-native and Sigstore tooling makes it the more common default for new setups, while Notary/TUF remains common where Docker Content Trust or formal TUF-based trust delegation is already established.
Does signing an image replace vulnerability scanning?
No — signing proves provenance and integrity (who built it, has it changed), not that the image is free of vulnerabilities. A signed image can still contain known-vulnerable dependencies; signing and scanning are complementary controls, not substitutes.
What happens if a signing key is compromised?
Every signature produced with that key becomes untrustworthy and should be treated as potentially forged going forward, which is why keyless signing (tying signatures to short-lived OIDC-issued certificates instead of a long-lived key) has become popular — there's no long-lived key to steal.
Is image signing required for SLSA compliance?
Provenance attestation — a close relative of signing — is a core requirement at higher SLSA levels, and signing is generally how that provenance attestation is delivered and verified in practice, though the exact requirement varies by which SLSA level a project targets.