Treat base images as dependencies. Pin them to a specific version or digest, scan every image you build, rebuild on a schedule so OS package fixes arrive, and record findings the same way you do for libraries. An auditor testing vulnerability management will not accept a gap just because a flaw lives below your application code.
Why images get missed
Teams track application libraries carefully, then build on a base image from months ago. That image carries an operating system layer with its own packages, and none of it appears in your package.json. A scanner that reads only manifests will not see it.
An image is a bundle of dependencies you did not choose one by one. It still runs your code with your secrets, so it belongs in scope.
Five controls for images
- Pin the base. Use an exact tag or, better, a digest, so a rebuild does not silently change the layer under your app. Record the reason when you update it.
- Scan at build. Run an image scan in CI and fail or flag according to your policy.
- Scan what is running. Images in a registry age. New advisories appear after you built, so rescan stored images on a schedule.
- Rebuild regularly. Fixes to OS packages only arrive when you rebuild on an updated base. Pick a cadence, such as weekly or on each release, and keep the pipeline run history.
- Keep it small. Fewer packages in the image means fewer things to patch and track. Remove build tools from runtime images.
Same policy, same exceptions
Do not invent a second process. Findings in image layers use the same severity bands, owners, tickets and exception records as library findings. Say so in your vulnerability policy: "applies to application dependencies and container images."
| Finding location | Fix usually looks like |
|---|---|
| Your application library | Upgrade the package |
| OS package in base image | Rebuild on a newer base |
| Base image itself unsupported | Move to a supported base |
| Build tool left in runtime image | Multi-stage build to drop it |
A caution about "no fix available"
Image scanners often report items for which the distribution has not shipped a fix. These need a decision: is the vulnerable component reachable, is there a mitigation, do you accept it for a bounded time? Record the decision with a review date, and avoid mass dismissal.
Evidence to keep
- Build pipeline logs showing the scan step on each image build.
- Registry scan history or monthly exports.
- A list of base images in use with versions and update dates.
- Exception records for accepted items.
If you ship the same few base images across many services, a short approved list makes both engineering and audit simpler.
Try it yourself
Open the demo and scan a container image. Look at which findings sit in the OS layer versus application packages.
Click through it at your own pace, or open it full screen.
Where Safeguard fits
Safeguard scans container images and dependencies, and its policies and gates can block builds that break your rules. Free scan: https://gold.safeguard.sh/scan.
Quick check
Do base image findings count toward my SOC 2 vulnerability control?
Yes, if images are part of the system you describe, which they usually are. Handle them under the same policy.
Is pinning by tag enough?
A tag can move. A digest is more precise. Whichever you choose, record when and why you updated it.
Sources
Last reviewed: 19 October 2026.
