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 who published it and that it hasn't been tampered with since. A consumer — a deployment pipeline, a Kubernetes admission controller — can verify that authenticity before running the image, instead of trusting it purely on faith. This closes a real supply-chain attack vector: without signing, nothing stops a compromised registry, a man-in-the-middle, or a malicious insider from substituting a tampered image under a trusted-looking name or tag.
Detailed Answer
The supply-chain risk signing addresses
docker pull myregistry.example.com/myteam/myapp:1.0
Without signing, this pull is an act of trust. You're assuming the image at this reference genuinely is what your team built and pushed, with no tampering along the way. Several real attack vectors could substitute something else under this same trusted-looking reference: a compromised registry account, a man-in-the-middle attack during push or pull (TLS mitigates but doesn't fully eliminate this), or a malicious actor with write access replacing the image content directly.
What signing actually proves
Signing an image cryptographically ties its content (specifically its digest) to a signing key held by a trusted identity — an individual, a CI/CD pipeline, or 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 signed by a key/identity I 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, is a widely adopted standard for signing and verifying OCI images. It supports traditional key-pair-based signing, shown above, plus keyless signing. Keyless signing ties a signature to an OIDC identity — a specific GitHub Actions workflow, or an individual's SSO identity — instead of requiring long-lived private keys to be generated, distributed, and protected. This is a real improvement, since key management is itself a common source of security failures.
Verifying signatures as part of deployment — the enforcement side
Signing alone doesn't help unless something actually verifies it before running the image. That's 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. Signing images doesn't help if nothing in the deployment pipeline actually checks and enforces that signature.
Why this matters more as supply-chain attacks have become more common
High-profile real-world supply-chain compromises — a build system compromise, or a maliciously modified widely-used base image or dependency — have pushed one idea to the front of security thinking industry-wide: verify what you're actually running, don't just trust the name/tag. Image signing is one layer of defense. Others include a Software Bill of Materials (SBOM), which catalogs exactly what's inside an image, and vulnerability scanning. Keep the distinction straight: scanning tells you what's inside an image, signing tells you whether you can trust it's genuinely what it claims to be. Neither replaces the other.