A container image is a frozen filesystem plus a little metadata about how to run it, and the whole promise of containers is that the thing you tested is the thing you ship. That promise only holds if you can answer a deceptively simple question: is the image running in production the exact one your build produced, and did your build produce it from ingredients you trust? Most teams reach for a friendly tag like web:latest and assume the answer is yes. Tags, though, are just mutable labels. The same tag can point at a different image tomorrow, which means “we deploy latest” is closer to “we deploy whatever someone last pushed under that name” than most people realize.
Container image trust is the practice of replacing that assumption with evidence. It rests on a handful of concrete, inspectable facts: the content digest that names an image by what it actually contains, the registry and repository it came from, a cryptographic signature asserting who published it, and provenance describing where and how it was built. None of these require you to trust a vendor’s marketing. They are checkable, and the defensive skill is learning to check them calmly rather than reacting to a scary tag.
The digest is the only name that cannot lie
A content digest is a cryptographic hash of the image’s contents. Because it is derived from the bytes themselves, it is a name that changes the instant anything inside changes. A tag says “the image someone chose to call api-v3”; a digest says “this specific image and no other.” When you pin a deployment to a digest, you get a property that is easy to underestimate: the workload cannot silently drift. If the registry entry behind a tag is overwritten, a tag-based deployment quietly picks up the new content, while a digest-pinned deployment keeps running exactly what it was pinned to until a human changes the pin. That is why a mismatch between the digest your pipeline recorded and the digest actually running is one of the cleanest signals in this whole area. It is a factual, timestamped discrepancy, not a matter of opinion, and it belongs in the same family of evidence discussed in Known-Good Baselines
.
Digests also give you a stable anchor for everything else. Signatures, vulnerability reports, and provenance statements can all be tied to a digest rather than a tag, so the question “is this attestation about the thing I am actually running” has a precise answer instead of a hopeful one.
Registries, signatures, and where an image was built
Where an image comes from is part of its trust story. Pulling from a registry your organization controls is not the same as pulling from an arbitrary public namespace, and “an image with the same name” from a different registry is a different image with a different owner. A common weak spot is a base image referenced by a floating tag from a public source: it may be fine today and something quite different after the next push. Preferring internal registries, mirroring the specific base images you depend on, and pinning them by digest all reduce the number of parties who can change what you run without your knowledge.
Signatures add the question of who is vouching for the image. A signature binds a publisher’s identity to a specific digest, so verifying it answers “did the party I expect actually produce this, and has it been altered since.” Modern signing approaches can tie that identity to a build system and a short-lived credential rather than a long-lived key someone might lose, which is the same identity discipline described in Service Accounts and Secrets . A signature is not a promise that the image is free of bugs; it is a promise about origin and integrity, and keeping those two claims separate keeps your reasoning honest.
Provenance goes one step further and describes how the image came to exist: which source commit, which builder, which steps. Provenance is what lets you answer “was this built by our pipeline from our reviewed code” instead of “was this built by someone, somewhere.” The evidence formats that carry signatures and provenance are the subject of the companion guide SBOMs, Signatures, and Attestations , and the two topics are best read together.
Toy example
Consider a fictional studio, Loomcraft, running a small service they deploy as loomcraft/checkout. Their pipeline builds an image, records its digest, signs it against their build identity, and deploys by digest. One morning a defender notices that a running checkout pod reports a digest that does not match anything the pipeline recorded for that release. That is the entire finding, and it is enough to act on without panic.
The calm write-up is narrow: “Pod checkout-7 is running digest sha256:… which does not appear in our pipeline’s published digests for the current release; the deployment manifest still references the expected digest; no signature for the running digest verifies against our build identity.” From there the questions are ordered and safe. Was there an out-of-band manual deployment or a rollback that legitimately introduced a different but still-signed image? Does the running digest carry any valid signature at all, or none? Was the registry entry changed, or the cluster manifest? Each answer either restores trust with evidence or narrows the concern. The point of the exercise is the ordering of questions, not the drama; nothing here involves attacking anything.
What evidence matters?
The first-class evidence is the digest comparison: the digest recorded at build time versus the digest actually running, pulled from the runtime and the registry rather than remembered. It is objective and it either matches or it does not. The second is signature verification against an expected identity, which turns “we think this is ours” into “this digest was signed by the builder we expect, and has not been modified since.” The third is provenance and build metadata, which connect the image back to a source revision and a builder so you can judge whether the ingredients were trustworthy, not just the wrapper.
Registry and admission logs are the connective tissue that makes the story reviewable. They show which image was pulled, by which node, at which time, and whether an admission control policy allowed or blocked it. Without those records you can often prove what is running now but not how it got there, and saying so plainly is better than guessing. As with any evidence work, the strongest notes are timestamped, exported, and tied to a named source rather than a screenshot, a discipline shared with Evidence-First Triage .
Common mistakes and false positives
The most frequent false alarm is a legitimate digest change. A routine rebuild, a rebased base image, or a normal rollback all produce a new digest, and none of them are incidents. Before treating a mismatch as compromise, check whether the new digest is itself signed by your build identity and traceable to your pipeline. A different-but-signed image is usually just a deploy you did not have in front of you; an unsigned or unexpectedly-published digest is the one that deserves attention.
The opposite mistake is over-trusting a green checkmark. A valid signature proves origin and integrity, not innocence: a genuinely-signed image can still contain a vulnerable dependency, and a passing vulnerability scan on an old digest says nothing about the one actually running. Keep the claims separated so nobody mistakes “authentic” for “safe.” A related trap is treating latest as a version at all; because it floats, two hosts pulling latest an hour apart may not be running the same code, which quietly undermines every other control. When a scanner lights up against an image, handle it the way Vulnerability Scan Findings Without Panic
advises: confirm the finding maps to the running digest before you escalate.
What to do next
Make the digest the unit of trust. Pin deployments to digests rather than floating tags, record the digest your pipeline produced as part of the release, and compare it against what is actually running when anything looks off. Require and verify signatures against an expected build identity, and prefer registries you control with the specific base images you depend on mirrored and pinned. Where you can, capture provenance so an image can be traced back to reviewed source, and keep registry and admission logs so the how-it-got-here question has an answer.
If a mismatch turns out to be a real intrusion rather than an untracked deploy, switch modes: preserve the running image, its digest, and the relevant logs as evidence, follow your incident-response plan, communicate through approved channels, and involve qualified responders. For learning, keep the images and identities fictional and rehearse the same calm sequence — compare the digest, check the signature, trace the provenance — until it feels routine.
How this guide was made
This page is defensive education built from public software-supply-chain frameworks and openly published container-security guidance, illustrated with an invented studio and toy identifiers. It claims no certification, compliance ruling, legal advice, or incident-response authority, and it avoids exploit detail on purpose so it stays useful for safe study rather than operational misuse.
Official references
To go deeper, the publications at the NIST Computer Security Resource Center cover software integrity and supply-chain practices in depth, and the CISA Secure Cloud Business Applications Project offers secure-configuration baselines that extend to the platforms images run on. The CIS Critical Security Controls v8 place inventory and integrity checking in a broader control set, while the CISA Known Exploited Vulnerabilities Catalog is a reminder that a trusted origin still needs patching. Use these as orientation rather than as a guarantee of safety.
Related guidebooks
The most natural companion is SBOMs, Signatures, and Attestations , which explains the evidence formats behind signing and provenance. From there, Service Accounts and Secrets covers the non-human identities that build and push images, and Storage Bucket Mistakes applies the same verify-before-you-trust habit to the data your containers read and write.
