Fix base image findings first because base layers sit beneath every later layer and are shared by many services. One rebuild on a patched base can clear dozens of rows across your estate, while an application fix helps one service. Rebuilding the base also rebuilds everything above it, so do it before app changes.
How layers stack
The OCI layer specification describes layers as filesystem changesets applied on top of each other to form the complete filesystem. Docker's layer documentation says each layer, once created, is immutable, and that images can extend others by reusing their base layers.
Two consequences follow for a scan.
First, findings in lower layers are inherited. Every service that starts from the same base tag carries the same operating system packages and the same rows. Second, Docker's cache documentation says that when a layer is invalidated, all layers after it are invalidated too. Changing the base therefore forces your install, copy and build steps to run again. If you fix the app first and the base later, you do two rounds of rebuilding and rescanning.
The order that saves work
- Group findings by layer or by base image. See base image rollup reports.
- Bump the base to a patched tag, using the pull flag, and rebuild one pilot service.
- Rescan and note what disappeared.
- Roll the new base across other services, as in rolling out a patched base image.
- Then work through what remains: language packages, your own installs, binaries.
What remains after the base bump
| Group | Typical share of remaining work | Owner |
|---|---|---|
| OS packages with no fix | Exceptions or a base change | Platform |
| Packages you installed in the Dockerfile | Update or remove | App team |
| Lockfile dependencies | Update lockfile | App team |
| Binaries compiled in your build | Rebuild with a patched toolchain | App team |
The exact shares depend on your images, so measure them rather than trusting a rule of thumb.
When base first is the wrong order
Base first is a default, not a law. Go straight to the app layer when:
- A finding is reachable and actively exploited in your own code path, and the fix is a small dependency bump.
- The base cannot change this week because of a freeze, but the app fix can ship.
- The base finding has no fix and an app finding does.
In those cases ship the app fix and schedule the base work.
Keep the base current
A base that is refreshed on a schedule means the next scan starts cleaner. Docker's guidance is to rebuild regularly and pull fresh bases. For who owns that schedule, see who owns base image vulnerabilities.
Where Safeguard fits
Safeguard's SBOM and dependency scanning keeps per image component data that can be grouped by origin, and its policies can enforce a base image standard. Free scan: gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Look for findings that many assets share.
Quick check
Does a base bump always reduce findings?
Usually, but a newer base can bring new packages, so rescan to see the net result.
Should every service bump its base on the same day?
Pilot one, then roll out in waves. That limits the blast radius of a behavior change.
Sources
- OCI image layer specification
- Docker, understanding image layers
- Docker build cache
- Docker build guidance
Last reviewed: 19 October 2026.
