What is image signing, and why does it matter for supply chain security?
Quick Answer
Image signing cryptographically attaches a verifiable signature to an image, proving it was published by a specific, trusted party and hasn't been tampered with since — letting a consumer (a deployment pipeline, a Kubernetes admission controller) verify an image's authenticity and integrity before running it, rather than trusting a pulled image purely on faith. This closes a real supply-chain attack vector: without signing, nothing technically prevents a compromised registry, a man-in-the-middle, or a malicious insider from substituting a tampered image under a trusted-looking name/tag.
Detailed Answer
The supply-chain risk signing addresses
docker pull myregistry.example.com/myteam/myapp:1.0
Without signing, this pull is fundamentally an act of trust. You are assuming the image at this reference genuinely is what your team built and pushed, with no tampering along the way. But several real attack vectors could substitute something else under this same trusted-looking reference. Examples include a compromised registry account, a man-in-the-middle attack during push/pull (mitigated by TLS, but not eliminated as a concern for the registry's own internal integrity), and a malicious actor with write access to the registry directly replacing the image content.
What signing actually proves
Signing an image cryptographically ties its content (its digest — see that question) to a specific signing key, held by a specific, trusted identity (an individual, a CI/CD pipeline's identity, an organization). A consumer verifying the signature isn't just checking "does this image exist at this reference." They're checking "was this exact content specifically signed by a key/identity I've decided to trust."
Cosign — a widely adopted modern signing tool
cosign sign --key cosign.key myregistry.example.com/myteam/myapp@sha256:a1b2c3...
cosign verify --key cosign.pub myregistry.example.com/myteam/myapp@sha256:a1b2c3...
Cosign (part of the Sigstore project) has become a widely adopted standard for signing and verifying OCI images. It supports traditional key-pair-based signing (as shown above) as well as keyless signing. Keyless signing ties a signature to an OIDC identity, such as a specific GitHub Actions workflow or a specific individual's SSO identity, rather than requiring long-lived private keys to be generated, distributed, and carefully protected. This is a meaningful practical improvement, since key management is itself a common source of security failures in traditional signing setups.
Verifying signatures as part of deployment — the enforcement side
Signing alone doesn't help unless something actually verifies the signature before running the image — this is where policy enforcement comes in:
# Conceptual example: a Kubernetes admission controller (like Sigstore's own
# policy-controller, or Kyverno -- see that stack's admission-controller question)
# configured to REJECT any Pod whose image isn't signed by a trusted, approved key
Pairing image signing with an admission-control policy that rejects unsigned or improperly-signed images closes the loop (in Kubernetes, this is done via a validating admission webhook — see that stack's question). It's not enough to sign images if nothing in the deployment pipeline actually checks and enforces that signature before allowing the image to run.
Why this matters more as supply-chain attacks have become more common
High-profile real-world supply-chain compromises, such as a build system compromise or a maliciously modified widely-used base image or dependency, have made one idea a much more prominent security concern industry-wide: verify what you're actually running, don't just trust the name/tag. Image signing is one layer of defense against this class of attack. Related practices form other layers, including generating and verifying a Software Bill of Materials (SBOM, cataloging exactly what's inside an image) and vulnerability scanning (see that question). The distinction worth keeping straight is this: scanning tells you what's inside an image, while signing tells you whether you can trust that it's genuinely what it claims to be. Neither one substitutes for the other.