In December 2020, attackers slipped a backdoor into a SolarWinds Orion software update that reached roughly 18,000 customers before anyone noticed. The build pipeline was trusted implicitly — nothing checked whether the binary that shipped was the binary that was actually built. Container images face the same exposure every day: a registry gets compromised, a CI token leaks, or a base image gets swapped in transit, and the image that lands in production is not the one a developer approved. Container image signing closes that gap by attaching a cryptographic signature to an image's digest at build time, so every later pull can be verified against that signature before the image is allowed to run. It's the mechanism that turns "we trust our registry" into "we can prove what we're running." Below is what image signing actually does, how it works under the hood, and where teams get it wrong.
What Is Container Image Signing?
Container image signing is the process of cryptographically binding a digital signature to a container image's SHA-256 digest so that anyone pulling the image can verify it hasn't been altered since it was built and was produced by an expected identity. The signature doesn't wrap the image file itself — it signs the immutable content digest, then stores that signature alongside the image in the registry (or in a separate transparency log) as an OCI artifact. When a Kubernetes node, CI runner, or admission controller later pulls that image, it recomputes the digest and checks it against the signature using the signer's public key or a certificate chain. If the digest doesn't match, or the signature doesn't verify, the image is rejected before a single container starts. This is distinct from scanning: a scanner tells you what's inside an image (CVEs, packages, licenses); signing tells you whether the image you're looking at is the one that was actually built and approved.
Why Does Container Image Signing Matter for Supply Chain Security?
It matters because unsigned images give attackers a way to substitute malicious content anywhere between build and runtime without detection. The 2021 Codecov incident showed how this plays out: attackers modified a bash uploader script hosted by Codecov, and it went undetected for roughly two months, exfiltrating credentials from thousands of CI environments that pulled it unverified. Container registries are exposed to the same class of risk — a compromised registry credential, a man-in-the-middle on an internal pull, or a malicious insider can push a tampered image with the same tag a legitimate build used. Executive Order 14028, issued in May 2021, directly cited this class of attack and pushed NIST to formalize software supply chain requirements in SP 800-218 (the Secure Software Development Framework, published February 2022), which explicitly calls for provenance and integrity verification of software artifacts — image signing is how that requirement gets implemented for containers.
How Does Container Image Signing Actually Work?
It works through public-key cryptography: a private key signs the image digest at build time, and a public key or certificate verifies that signature at deploy time. The traditional model uses long-lived key pairs — Docker Content Trust, built on Notary, worked this way starting in 2015, requiring teams to generate, rotate, and protect a root key that, if lost or leaked, undermined the whole chain of trust. The modern approach, popularized by Sigstore (launched by the Linux Foundation in 2021 with backing from Google, Red Hat, and Chainguard), uses "keyless" signing: instead of a static key, the signer authenticates via OpenID Connect (tying the signature to a CI workflow identity or a developer's SSO login), receives a short-lived certificate from Sigstore's Fulcio CA, and the signing event is recorded permanently in Rekor, a public transparency log. This removes the operational burden of key management and creates a public, tamper-evident record of who signed what and when. Cosign, Sigstore's CLI tool, became the de facto way to attach these signatures to OCI images, and Sigstore was accepted as a CNCF incubating project in March 2022.
What Tools Do You Actually Use to Sign Container Images?
The two dominant tool families are Sigstore/Cosign and the Notary Project (Notation), and most teams pick based on whether they need keyless or key-based signing. Cosign supports both keyless signing via Fulcio/Rekor and traditional key-based signing (including keys stored in AWS KMS, Google Cloud KMS, Azure Key Vault, or HashiCorp Vault), and it integrates directly into docker buildx and most CI systems with a single cosign sign command. Notation, the successor to Notary v2, is a CNCF project built around the OCI signature specification and is the tool Microsoft and AWS have standardized around for their managed registries (Azure Container Registry and Amazon ECR both have native Notation integration). Docker Content Trust still exists but has largely been superseded because it only supports Docker Hub-style tag signing rather than the digest-based OCI signature model that Kubernetes environments expect. For most net-new pipelines in 2026, Cosign with keyless signing is the default choice because it eliminates key custody as an operational problem.
How Do You Enforce Image Signing at Deploy Time?
Enforcement requires an admission controller in the cluster that rejects any pod whose image doesn't carry a valid, policy-matching signature — signing an image does nothing on its own if nothing checks for the signature before scheduling. Kyverno and Connaisseur are the two most common open-source enforcement points; Kyverno's verifyImages policy rule can require that every image in a namespace be signed by a specific Cosign key or a Fulcio certificate matching a specific GitHub Actions workflow identity, and it will block the pod at admission time if verification fails. Sigstore's own policy-controller (part of the Sigstore project) does the same job natively for keyless signatures. A policy might require, for example, that every image deployed to a production namespace was signed within the last 90 days by a certificate issued to https://github.com/org/repo/.github/workflows/build.yml, which ties deployment eligibility directly to a specific, auditable build pipeline rather than a static credential that could be copied or leaked.
What Goes Wrong When Teams Implement Image Signing?
The most common failure is signing images without enforcing verification anywhere, which gives teams a signature they never actually check. A 2023 survey-driven report from Sysdig found that a majority of organizations running Kubernetes had no admission control policy verifying image provenance at all, meaning signing effort — if it existed — was purely decorative. The second most common failure is signing the wrong artifact: teams sign a tag (like myapp:latest) instead of the immutable digest, and tags are mutable, so a signature on a tag provides no guarantee about what's actually running once that tag gets repointed. A third failure is treating signing as a replacement for scanning rather than a complement to it — a signature proves an image wasn't tampered with after signing, but it says nothing about whether the image was safe to sign in the first place, which is why signing needs to sit downstream of vulnerability and SBOM checks in the pipeline, not instead of them.
How Safeguard Helps
Safeguard treats image signing as one checkpoint in a chain of build-time evidence rather than a standalone control. Safeguard generates and ingests SBOMs for every image in the pipeline, then runs reachability analysis to determine which signed images actually expose exploitable code paths in production rather than flagging every CVE a scanner finds. Griffin AI, Safeguard's reasoning engine, correlates signature status, SBOM contents, and reachability data to prioritize which unsigned or misconfigured images represent real risk instead of noise, and it can open auto-fix PRs that add Cosign signing steps or Kyverno enforcement policies directly into a team's CI/CD configuration. That combination lets security teams move from "we have signatures somewhere" to "we can prove, per deployment, which images were verified and why they were trusted" without hand-building the admission control layer themselves.