A base image update changes many operating system packages at once, so the SBOM diff looks alarming even though one decision caused it. Confirm the image digest changed, group the package changes under that single cause, then review only packages your application calls or ships on purpose.
Why one change looks like fifty
A container image is layered. The base layer carries the operating system and its packages. When the base tag moves to a newer build, nearly every package version can shift, and an SBOM generated from the image lists each one. The diff is faithful, and also mostly noise for a reviewer.
Step by step
- Compare the base image reference and digest in both builds. A tag such as latest can point to different content on different days, so the digest is the reliable identifier.
- Check whether the Dockerfile changed. If not, an unpinned tag moved underneath you. That is a finding of its own.
- Split the diff into two groups: packages that came from the base image, and packages your build added on top.
- Treat the base group as one review item: why did the base change, and is the new one the intended release.
- Review the second group the usual way, one component at a time.
What to read in the base group
| Pattern | Reading |
|---|---|
| Versions mostly moved forward | Normal refresh, check advisories fixed by it |
| A package vanished | The new base is slimmer, confirm nothing you rely on went with it |
| A new package appeared | Check why, since extra packages mean extra attack surface |
| A major version of a core library changed | Test behavior, not just security |
| Packages moved backward | Unusual, investigate before shipping |
Pin to stop surprises
Pinning the base image by digest makes updates deliberate. A digest never changes under you, so the SBOM diff changes only when someone edits the Dockerfile. Pair that with a scheduled job that proposes digest updates, so the base does not go stale either.
The trade off is real. Pinned images stop receiving fixes until someone moves the pin. Without a refresh routine, a pin trades surprise for neglect. Set a cadence and an owner.
Match the diff to vulnerability data
After grouping, compare vulnerabilities fixed and introduced between the two images. A base update that clears known issues is good news you can report. One that introduces a new high severity finding in a package you do ship deserves a stop. Reachability analysis helps here by separating packages the application actually calls from those that only sit in the image.
Safeguard scans container images and uses reachability analysis to prioritise findings. The free scan is a quick way to see an image or project inventory.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at which findings come from the operating system layer and which come from application dependencies.
Quick check
Should I pin base images by digest?
Pinning makes changes deliberate, but add a routine to refresh the pin so the image does not go stale.
Do I have to review every package in the base group?
No. Review the base change as one decision, then focus on packages your application calls or you added.
Last reviewed: 19 October 2026.
