Examples in this article are illustrative, not customer case studies. Product availability and coverage are described on the linked capability pages.
A registry scan flags a serious vulnerability, and your team spends a day proving the image has not run in production for months. This post shows how binding container images to running workloads by digest turns a registry inventory into an exposure list you can prioritise with confidence.
Image-to-workload binding links each running container to the exact image digest it pulled, so a vulnerability found by a registry or build scan can be matched to the workloads actually running that content. Binding by digest rather than tag is what makes the match verifiable instead of inferred.
Our example is a checkout service. Its registry repository holds dozens of tags: current releases, rollback candidates, images from abandoned feature branches. One image is running behind a public ingress right now, and a scan has just found a vulnerable HTTP parsing library in several of them. The question that matters is which of those findings describe something an attacker can reach today.
A scanned container image is inventory until a workload runs it
Registries accumulate images the way disks accumulate files. Old release tags kept for a rollback that never happens, branch builds nobody deleted and base images pulled once for evaluation all get scanned, and all produce findings. If every finding is treated as equally urgent, the volume alone guarantees the report is triaged badly or not at all.
The distinction that matters is whether an image is running, and if so, what that instance can reach. A vulnerable checkout image that was never deployed carries risk only in the sense that someone might deploy it later. That is worth fixing before it happens, but it is categorically different from the same library running behind a load balancer with a public address.
Collapsing the two is how security teams end up asking engineers to drop everything for an image nobody has run in months. Alerts like that train people to stop reading reports, which is the most expensive outcome of all.
Bind container images to workloads by digest
Getting from “this image is vulnerable” to “this workload is exposed” requires a precise link, because errors cut both ways. A false positive wastes an incident response. A false negative leaves a real exposure open while dashboards say otherwise.
The only reliable anchor is the image digest, the content-addressed hash that identifies exactly what was scanned. Even when a Kubernetes manifest references a tag, each running container reports the digest it actually pulled, and that is the same identifier the registry scan ran against. Binding on digest makes the claim “this workload runs this scanned content” verifiable rather than inferred.
Anything looser, such as image name plus a rough package version, produces a mapping that looks plausible and is regularly wrong. The error usually surfaces at the worst moment, when someone asks a pointed question during an incident.
Mutable tags make tag-based binding unreliable
Tags are mutable by design, which is exactly what makes them unsafe as a security identity. The checkout team’s checkout:2.3.1 looks pinned, but a rebuild can reuse the tag, a hotfix can be pushed under it to avoid editing manifests, and a manual push during an incident can repoint it entirely.
A scan result keyed on a tag can therefore go stale the moment someone pushes again, without any manifest changing. The pod spec still says checkout:2.3.1, while the content behind that tag is no longer what was scanned. A team relying on tags can report a workload clean on the strength of content it no longer runs, or flag it for content it never ran.
Tag reuse is routine and usually done for sound operational reasons. The answer is not to ban it, but to stop treating tags as identity and resolve every binding to the digest actually running.
Prioritise container findings by what the running workload can reach
Once images are bound to workloads by digest, prioritisation can use context a registry never has. You can ask whether the workload is reachable from outside the cluster, what its service account is permitted to do, what else it can reach, and whether the vulnerable package sits on a code path the service executes.
The checkout service handles inbound requests through the vulnerable parser on every call, behind a public ingress, with a service account that can read payment tokens. A nightly reporting job built from an older image carries the same library, but it has no ingress, never parses untrusted input and runs with a narrowly scoped account. The CVE is identical, yet the urgency is not. The routing side of this, getting each finding to the team that owns the workload, is covered in vulnerability ownership routing by graph.
A base score describes a vulnerability in the abstract. Exposure describes whether anyone can reach it now, and that second question decides whether a finding needs attention today or can wait for the next patch cycle.
Verify the replacement image and the rollout
Closing a container finding has the same evidential standard as closing an IaC finding: check what is running, not what was merged or pushed. The evidence is a workload resolving to a new digest, built from an updated base or with the library bumped, and that digest replacing the old one in the live cluster rather than waiting in the registry.
Watch deliberately for the quiet failure. A fixed checkout image is built and pushed, the rollout fails or rolls back, and the vulnerable digest keeps serving traffic while every dashboard upstream of the cluster shows the fix as shipped. Only a check against the live workload catches this. Admission policy that refuses unapproved digests closes the loop, as described in Kubernetes admission gates and cluster drift.
Key takeaways
- Key every image-to-workload binding on the running digest, never on a tag.
- Rank container findings by the workload’s reachability and permissions, not by base score alone.
- Treat images that no workload runs as backlog, and fix them before anyone deploys them.
- Verify that the replacement digest removes the issue and that affected workloads have rolled over; absence of the old digest alone is not proof of a fix.
How SecurityVault approaches this
SecurityVault uses reported image digests to associate collected Kubernetes workloads with image findings. That association helps prioritise known running exposure and identify owners. Missing or stale cluster data is an evidence gap. After remediation, verify both the replacement image and the affected deployment. eBPF execution signals remain planned and are not available today.
During evaluation, deploy two different digests under the same image tag in a controlled environment. Compare the recorded associations with the container runtime state, then replace one deployment and refresh inventory. The review should distinguish current observations from historical ones and show any uncollected workload. Pair that check with a scan of the replacement image. This tests the connection that matters to incident responders: which known deployment carries the affected content now, rather than which tag happened to have a matching name earlier.
Explore Container security or talk to our team about an evaluation with your engineering, security and compliance stakeholders.