A sidecar image runs inside your service's pod, but it is usually owned by whichever team supplies it, often a platform team. Record the owner of each sidecar image separately from the application owner, then fix it at the source and roll it out to every pod that includes it.
What a sidecar is
Kubernetes describes sidecar containers as secondary containers that run alongside the main application container in the same pod, adding functions such as logging, monitoring, security or data synchronisation without changing the application code. They are defined as init containers with restartPolicy: Always. The documentation says sidecars first appeared in version 1.28, were enabled by default from 1.29, and became stable in 1.33.
That means a pod can have several images, each with its own packages and advisories, and often more than one owner.
Why sidecars get lost
Scans that start from application repositories never see them. A log shipper injected by a platform template appears in the running pod but not in the service's source. Findings then have no home.
Find them
- List every container image per pod in each cluster, including init containers and those marked as sidecars.
- Group images by repository and tag or digest.
- Mark the images that appear in many pods with different application names. Those are shared sidecars.
- For each, find the supplier: which team builds or selects it.
Assign ownership
| Image type | Typical owner | Fix route |
|---|---|---|
| Application container | Service team | Rebuild the service |
| Shared logging or monitoring agent | Platform or observability team | Publish new image, roll to pods |
| Security agent | Security engineering | Update through the agent's own mechanism |
| Injected proxy | Platform team | Update injection configuration, restart pods |
Add this as a column in your inventory, next to the application owner.
Fixing at scale
When a shared sidecar has an advisory, the supplying team publishes the fixed image and updates the shared template. Services then need a restart or redeploy to pick it up, so give them a window. If sidecars are injected at pod creation, a rolling restart may be all that is required. Check how your setup injects before promising that.
Record the version
Use the recommended labels such as app.kubernetes.io/version and app.kubernetes.io/component to mark which container is what. It helps queries like "all pods running version X of the log shipper".
Try it yourself
Open the demo to see how an image scan breaks findings out by package. Imagine running it on each image in a pod, not just the application.
Click through it at your own pace, or open it full screen.
Quick check
Is the service team responsible for sidecar findings?
Not always. Agree up front who supplies each sidecar, and route findings to that team.
Do sidecars show up in an application SBOM?
Only if you generate component data per image in the pod. An application SBOM alone will not include them.
Safeguard's container image scanning and asset discovery work per image, so every container in a pod can be covered. A free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
