Run a kubectl get pods across all namespaces with a jsonpath that reads initContainers and containers, then sort and count the output. That gives you every image in use right now. Add ephemeralContainers if you want debug containers too, and remember it only shows pods that exist at this moment.
The command
The Kubernetes documentation gives this pipeline for listing images in all namespaces, init containers included.
kubectl get pods --all-namespaces \
-o jsonpath="{.items[*].spec['initContainers', 'containers'][*].image}" |\
tr -s '[[:space:]]' '\n' | sort | uniq -c
The jsonpath walks each pod item, reads the spec, and prints the image of every init and regular container. The tr, sort and uniq steps turn the single line into a counted list. The most used images show up at the bottom of a sorted count if you add sort -n.
What the docs do not cover
The documented page does not read ephemeral containers, which are the debug containers added by kubectl debug. The union can be extended to include the ephemeralContainers field. Check that on your cluster version before you rely on it.
The command also does not tell you which workload owns a pod. If you want a per image, per namespace view, use the range form from the same page or output JSON and process it with a script.
Turning the list into a scanning queue
- Save the list with a date.
- Strip duplicates, keeping the count as a weight.
- Resolve each tag to a digest, since tags can move.
- Scan each unique digest once, not once per pod.
- Join findings back to namespaces and owners.
Step four is where scale comes from. Five hundred pods often run far fewer distinct images. Scanning images, not pods, cuts the work and removes duplicate findings.
Limits to remember
- A snapshot is only as good as the moment you took it. Scheduled jobs that are not running will be missing.
- Pods in other clusters are not here. Repeat for each cluster.
- The image name does not say whether the code inside is vulnerable. It only says what to scan.
Run the command on a schedule and diff the results. A new image that appears with no matching repository is worth a question.
Quick check
Does this list images that are in the registry but not running?
No. It lists images referenced by pods that exist now. Use your registry listing for the rest.
Why resolve tags to digests?
Because a tag can point to different content over time. A digest is a hash of the image content and does not move.
Safeguard can scan container images and dependencies, and you can try a free scan first.
Sources
Last reviewed: 19 October 2026.
