Match the action to where the finding lives. Base layer finding with a fix: rebuild on a fresh base. Your own layer: change the Dockerfile or dependency file. No fix and no use for the package: remove it or switch base. No fix and needed: record a time limited exception. Never patch a running container.
Why the layer decides the action
Each image layer is a set of filesystem changes and, once created, is immutable, as the Docker documentation puts it. You cannot edit a finding out of an old layer. You build a new image with different layers. So the useful question is which layer brought the package in, because that tells you which input to change. See what a container image layer is.
The decision table
| Finding location | Fix available? | Action | Owner |
|---|---|---|---|
| OS package in base layers | Yes | Rebuild with a fresh pull of the base tag | Platform or app team |
| OS package you installed in a Dockerfile step | Yes | Rebuild; check the install step is not cached | App team |
| Language package from your lockfile | Yes | Update the lockfile, rebuild | App team |
| Runtime or interpreter binary | Yes | Move to a patched image tag | App team |
| Package you do not need | Any | Remove the install step or use a smaller base | App team |
| Any package | No | See no fix available | Security with app team |
| Fix just in a newer OS release | Newer release alone | Plan a base image move, or record an exception | Platform |
Rebuild
Docker's build guidance page recommends rebuilding images regularly because an image is a snapshot, and using the pull flag so the build fetches a newer base instead of reusing a cached one. The no cache flag forces every step to run again, and the page says the two serve different purposes and can be combined.
docker build --pull --no-cache -t myapp:2026-10-19 .
Use the no cache flag when a cached install step may be holding old packages, not on every build, since it is slower.
Patch
Patching in place, such as running a package upgrade inside a live container, changes just that container's writable layer. It disappears on restart and leaves the image unchanged. Patching inside the Dockerfile at build time is legitimate, and the trade-offs are in apt upgrade or rebuild.
Replace
Replace the base when a family of findings keeps returning because the base is large, old or reaches its support end. A smaller base reduces packages, and fewer packages means fewer rows. Moving needs testing, since a different C library or shell can change behavior.
Accept with an expiry
If nothing can be fixed now, write the exception with an owner, a reason, a review date and the compensating control. Machine readable status helps downstream readers; see suppress with expiry and VEX.
Order of work
- Fix findings in shared base layers first, since one change helps every service. See roll out a patched base image.
- Then your lockfile findings.
- Then exceptions and removals.
Where Safeguard fits
Safeguard's reachability analysis and policies help rank findings so the first rebuild covers what matters. Autonomous remediation with fix PRs is available but off by default, with every category on Manual until you change it. Free scan: gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Look for which findings have a fix ready.
Quick check
Is running apt upgrade in a live container a fix?
No. It changes one running container, not the image, and the change is lost when the container is replaced.
When is replacing the base worth the effort?
When the same classes of finding keep returning, or the base is at or near its support end.
Sources
Last reviewed: 19 October 2026.
