Can a deployment prove which container image it runs?

Key Stats

• 1 deployment revision is the unit of analysis
• 3 independent evidence layers: build, registry, and runtime
• 4 failure cases tested before an image identity claim is accepted

Key Takeaways

• A mutable tag is a label, not proof of image identity.
• Join the source revision, built digest, admitted digest, and running workload.
• Keep production admission exceptions with the internal platform or security owner.

Research question

Can a distributed engineering team demonstrate that a running workload came from the reviewed source and build, rather than merely showing that a familiar image tag appears in a deployment file? This question matters when a Philippines-based offshore developer prepares an application change while a client-side platform owner controls the registry, cluster, and release approval. The research unit is one deployment revision, one image manifest digest, and the workloads created from it. The claim under examination is narrow: whether the evidence identifies the artifact that ran. It does not certify every dependency, prove the source is safe, or transfer production authority to the developer.

Evidence scope and method

The method follows the artifact through four records. First, record the reviewed source revision and the build definition. Second, capture the registry digest emitted for the resulting image. Third, inspect the deployment specification after admission or mutation. Fourth, query the running workload for the resolved image identifier. Repeat the trace with a moved tag, an unapproved registry, a failed signature or provenance check, and a rollout containing both old and new replicas. Preserve command output, timestamps, environment names, and tool versions. Facts are the recorded identifiers and policy results. Analysis is the judgment that those records form an unbroken identity chain.

What the standards establish

Kubernetes documentation states that tags can move while digests identify fixed image content. Its security checklist recommends digest references or provenance validation at admission. NIST Secure Software Development Framework guidance calls for protecting software from tampering and retaining provenance information for releases. These sources support controls, not a conclusion about a particular application. A deployment manifest containing a digest is factual evidence about declared intent. It is not yet evidence that admission left the reference unchanged, every replica updated, or the observed process came from the reviewed build. Those points require local observations tied to the same rollout.

The mixed-replica problem

A rollout can be healthy by its controller rules while old and new replicas coexist. A single successful pod inspection therefore creates a selection bias. The sample should include every replica owned by the target revision and report its image ID, readiness state, start time, and controller revision. If a node cached an image, the declared pull policy also belongs in the record. The useful result is not a screenshot of one green workload. It is a reconciliation showing which digest each eligible replica ran during the observation window and whether traffic could still reach a previous digest. This is where asynchronous handoffs need exact identifiers rather than phrases such as "the latest build."

Testing counterclaims

The first counterclaim is that a release tag is sufficiently stable because the team never intentionally moves it. Test that assumption in an isolated registry or with a synthetic tag and show whether the same deployment text resolves differently later. The second is that a signed image proves source identity. A signature only supports the claim expressed by its policy and signer; the reviewer must inspect the trusted identity, issuer, subject, and verified digest. The third is that a digest alone proves the build was reviewed. It does not connect the artifact to source or build controls. Each counterexample narrows what the evidence can honestly establish.

Division of work across the team

An offshore developer can add digest capture to a build, prepare a deployment diff, collect non-sensitive registry metadata, write policy fixtures, and document a reconciliation command. The developer can also test rejection behavior in an approved non-production environment. The internal platform or security owner chooses trusted builders and signers, configures admission, grants registry access, approves exceptions, and decides whether production evidence is sufficient. This boundary prevents a person who created an artifact from unilaterally approving its trust chain. It also gives the developer a concrete deliverable that a reviewer in another time zone can reproduce.

Limitations

This approach does not prove that build infrastructure was uncompromised, that the base image remained appropriate, or that a running process behaved as intended. Registry retention, multi-architecture manifests, admission mutation, sidecars, init containers, and ephemeral containers can widen the inventory. Cluster observations can change immediately after collection. Signature and provenance formats also depend on the organization’s trust policy. The report should state which container classes, namespaces, architectures, and rollout interval were observed. Missing access is a limitation, not a reason to infer a clean result from the deployment repository alone.

A review packet that survives the time-zone handoff

The final packet should be small enough for a platform reviewer to inspect without reconstructing the release. Include the source revision, build run identifier, image name and digest, provenance verification result, admitted workload revision, replica inventory, and the exact observation time. Redact credentials and avoid copying broad cluster configuration. Add the four negative-case results beside the normal path so the reviewer can see what the controls reject. A mismatch should name both values and stop short of recommending production promotion. This format turns an overnight development task into a bounded morning decision: accept the identity chain, request one missing link, or reject the release artifact.

Evidence-led conclusion

The evidence supports an image identity claim only when the reviewed source, build output, registry digest, admitted specification, and running replicas can be reconciled for the same bounded release. Tags remain useful names, but their convenience should not be mistaken for immutability. For a distributed development arrangement, the practical handoff is a compact artifact record plus a reproducible runtime check. The internal owner then decides whether provenance and admission policy meet the organization’s risk threshold. If any link is absent, the correct conclusion is narrower: the team knows what was declared, built, or observed, but not all three.

Evidence table

Good distributed work is observable at the handoff: the result, evidence, limitations, and next owner are all explicit.

Frequently asked questions

Related Research

• Research library
• Developer services
• Daily developer guides