Yes. Init containers and sidecars each have their own image field, their own packages and often their own privileges. If your scanning covers only the main app image, you are skipping part of every pod. Include initContainers in every inventory query and every policy.
How Kubernetes defines them
Init containers are listed under .spec.initContainers and run to completion before the app containers start. Sidecar containers are also declared under initContainers but with restartPolicy: Always, which keeps them running for the life of the pod. The Kubernetes documentation says sidecar containers have been stable since v1.33.
The init container documentation states that init containers have separate images from app containers and support the same security settings, including resource limits and volumes. It also notes they can be given access to Secrets that app containers cannot read.
That last point is the reason to care. A vulnerable image in a container that can read a Secret is a more serious finding than the same image with no access.
Why they get missed
| Reason | Fix |
|---|---|
Queries read only .spec.containers | Add initContainers to the jsonpath or policy |
| Sidecars are injected by a mesh or agent at admission | Scan the injector's image and its configured version |
| Helm charts hide them in templates | Render the chart and scan the output |
| Teams treat them as infrastructure | Give each one an owner in the registry of workloads |
The Kubernetes example for listing images uses ['initContainers', 'containers'] precisely because the simpler per-pod commands skip init containers.
Steps to cover them
- Inventory every image from rendered manifests and from the live cluster, including init containers.
- Scan each image by digest, the same as app images.
- Write admission rules against both fields. A rule on
containersalone can be bypassed by moving a workload intoinitContainers. - Review privileges. Check the security context of each init container and sidecar, and drop what they do not need.
- Pin injected sidecars to a version you control instead of whatever the injector picks.
A note on injected sidecars
Some sidecars never appear in your manifests because a webhook adds them when the pod is created. Your Git history will not show them. Only the live cluster, or the admission-time view, does. That makes them a good argument for scanning what runs rather than only what you committed.
Quick check
Is a short-lived init container a lower risk?
It has a smaller window, but it runs before the app and may hold Secrets or elevated rights. Scan it.
Does one image scan per pod cover everything?
No. A pod can contain several images. Scan each distinct image in the pod spec.
Sources
- Init Containers, Kubernetes docs
- Sidecar Containers, Kubernetes docs
- List All Container Images Running in a Cluster
Safeguard scans dependencies and SBOMs and applies policies and gates across what you run; the free scan is a quick way to see the inventory.
Last reviewed: 19 October 2026.
