To find pods running a vulnerable image, list every image in the cluster with kubectl, including init containers, resolve each to a digest, match the digests against the image's package inventory, then map each match to a workload owner. Do it from the running cluster, not from your Git history.
Step 1: list what is actually running
The Kubernetes documentation gives a command that counts every image across all namespaces and includes init containers:
kubectl get pods --all-namespaces -o jsonpath="{.items[*].spec['initContainers', 'containers'][*].image}" | tr -s '[[:space:]]' '\n' | sort | uniq -c
The same page notes that its per-pod, per-label and per-namespace variants read only regular containers. If you reuse those, add initContainers to the jsonpath or you will miss images.
Step 2: get digests, not tags
A tag such as 1.4 can point at different content on different days. The Kubernetes documentation states that digests are immutable and tags can be moved. The running digest is in each pod's status under containerStatuses and initContainerStatuses, in the imageID field. Record that value. It tells you which build is live on that node.
Step 3: match against a package inventory
You need to know which packages are inside each digest. There are two routes:
| Route | Good for | Weak spot |
|---|---|---|
| Scan each running digest on demand | Fresh answer for one CVE | Slow across hundreds of images |
| Keep an SBOM per digest and query it | Fast answer when a new CVE drops | Only as good as how often you refresh |
The second route is what turns a panic into a query: search the stored inventories for the affected package and version range, and get a list of digests.
Step 4: map digests to owners
For each affected digest, list the pods and read their labels and owner references. Look for a team label, a repo annotation or a Helm release name. If your pods carry none of these, add them now; the next incident will thank you.
Step 5: decide order of work
Not every match is equally urgent. Prioritize internet-facing workloads, workloads where the vulnerable function is reachable, and findings with known exploitation. A match in a job that ran once last month is lower.
Try it yourself
Click through it at your own pace, or open it full screen.
Search the inventory for a package name and see how quickly the affected components appear.
Safeguard builds SBOMs and scans dependencies so that a package search across your inventory is a query rather than a project. The free scan shows what an inventory looks like.
Quick check
Why not just search our repositories?
Repositories show what was intended. The cluster shows what runs, including old images no one rebuilt.
Do I need to check init containers?
Yes. They have separate images and can carry vulnerable tools. Include them in every query.
Sources
Last reviewed: 19 October 2026.
