Container Image Provenance: Signing Is Half the Control

A signature proves origin, not safety

Image signing has become a default recommendation, and the recommendation is correct as far as it goes. A signature proves that a particular build produced a particular image digest and that the signer held a key. It does not prove the build was trustworthy, that the base image was current, or that the running cluster checks the signature before starting a workload.
Most programmes stop after signing, which produces a cryptographic artifact and no change in behaviour.

Three properties that have to hold together

Provenance. The signature must be bound to a claim about how the image was built: which source commit, which builder, which pipeline identity. A signature over the digest alone records who signed, not what was inside.
Verification at admission. The cluster must refuse to run an unsigned or unverifiable image. Without admission control, the signature is an audit record and an attacker with registry write access is unaffected.
Key custody. The signing key must live where a build compromise cannot read it. A key stored as a long-lived secret in the same pipeline it signs is not a control; it is an additional credential to steal.

Where implementations go wrong

Admission policies are often scoped to a single namespace or exempt the system namespaces, which is precisely where a durable foothold is easiest to place. The exemptions are usually added to keep the cluster running during the rollout and then never removed.
Verification is sometimes configured to warn rather than to deny. A warning produces a log entry that nobody reads and a workload that starts anyway.
Signatures are checked against a key or certificate without verifying the identity of the pipeline that requested it. Combined with a shared signing key, this means any repository in the organisation can produce an image that passes verification.
Base image updates are not part of the loop. A signed image built on a base with a known vulnerability passes verification indefinitely, because the control checks origin and says nothing about freshness.

Defensive implications

Treat admission control as the control and signing as its prerequisite. If the enforcement point is not blocking, the programme is not yet doing anything.
Issue signing identities per pipeline, and bind the signature to a claim about the source. A signature that does not name the source commit cannot support an incident investigation.
Verify digests rather than tags at deploy time. A tag is mutable, and a mutable reference in a deployment manifest undoes the guarantee the signature provides.
Track base image age as a separate metric with its own remediation path. Signature validity and patch currency are different questions.
The limit is worth stating plainly. Provenance controls the artifact pipeline. It does not constrain what the application does at runtime, and it will not detect a vulnerability introduced by legitimate code. It closes the specific gap where an attacker who can write to a registry can run arbitrary code in the cluster.