Often not. Many programs scan the application image from each repository and miss the extra images that run in the same pod, such as sidecars, init containers and debug containers. Read the pod specs from the cluster, list every image, and include them in your scan queue.
Why they get missed
Repository based scanning sees what a team builds. Sidecars are usually added by a platform tool, a template or a mutating webhook. Init containers are often a utility image copied from an old example. Nobody on the service team feels they own them, and the scanner never sees a repository for them.
Yet they run beside your code, often with access to the same network, volumes or secrets.
How to find them
The Kubernetes documentation gives a jsonpath that reads both initContainers and containers across all namespaces, which already covers init containers and sidecars defined as regular containers. The same page does not read ephemeral containers, the debug containers added with kubectl debug. Add that field if your cluster version supports it, and test it first.
kubectl get pods --all-namespaces \
-o jsonpath="{.items[*].spec['initContainers', 'containers'][*].image}" |\
tr -s '[[:space:]]' '\n' | sort | uniq -c
Compare this list with the images your repository scans cover. The difference is your blind spot.
Classify what you find
| Kind | Typical owner | Action |
|---|---|---|
| Mesh or proxy sidecar | Platform team | Scan and update on the platform schedule |
| Log or metrics agent | Platform or observability | Same |
| Init utility image | Service team | Replace with an approved base |
| Debug image | Whoever ran it | Remove after use |
Close the gap
- Add every cluster image, not just built images, to the scan queue.
- Assign an owner for each non-application image, even if it is a shared platform team.
- Add the images to your approved list or retire them.
- Alert when a new image appears that is not on the list.
- Make sure rebuilds pick up newer versions, since images are snapshots of their contents at build time.
Version drift
Sidecars tend to be the same image on hundreds of pods, at different versions. A rollup by digest shows how far behind each cluster is. One update can fix many pods, but it needs a rolling restart, so coordinate with the owners.
Quick check
Do scanners that read my repositories see sidecars?
Only if the sidecar is defined in your manifests. Injected ones are visible only in the running cluster.
Who owns an injected sidecar?
Usually the platform team that configures the injection. Write it down in the catalog.
Safeguard scans container images, and a free scan is a starting point for a single project.
Sources
Last reviewed: 19 October 2026.
