A rebuild often reuses a cached base image or cached layers, so the vulnerable component survives. Docker documents two separate flags: one fetches a newer base image, the other re-runs build steps without the cache. Which one you need depends on where the vulnerable package lives. Always scan the result.
What Docker says
Docker's build guidance says images are immutable: building an image is a snapshot of that moment, including base images and libraries. It advises rebuilding regularly with updated dependencies. It notes that a tag such as a version of a base image may resolve to a different underlying image over time as the publisher rebuilds it with new patches, and that a pull flag forces Docker to check for and download a newer base image even if a local copy is cached. A no-cache flag disables the build cache and re-runs every layer. The docs state the no-cache flag gets the latest available versions of dependencies from package managers, does not pull a fresh base image, and that the two flags serve distinct purposes and can be combined.
# fresh base image, cached steps
docker build --pull -t app:fix .
# cached base, all steps re-run
docker build --no-cache -t app:fix .
# both
docker build --pull --no-cache -t app:fix .
Where is the flaw?
| Flaw lives in | What you need |
|---|---|
| The base image's operating system packages | Fresh base image (pull) |
| A package installed by a package manager step | Re-run that step (no-cache or a changed layer) |
| Your application dependencies | Updated lockfile, then rebuild |
| A copied binary | Replace the file in the build context |
If you rebuild without the right flag, the build succeeds, the tests pass, and the vulnerability remains. This is why a green build is not evidence of a fix.
Steps to fix it properly
- Identify the layer. Scan the current image and see which package and layer carry the flaw.
- Update the source. Change the lockfile, the base tag or the install step.
- Rebuild with the right flags. Use pull when the base changed upstream.
- Scan the new image. Confirm the finding is gone.
- Deploy by digest. Make sure the running container uses the new image, not a cached tag on a node.
- Verify in the running environment. Check the digest actually running.
Pinning without staleness
Docker's guidance also suggests pinning base image versions. Pinning gives repeatable builds, but a pinned digest never updates by itself. If you pin, pair it with an automated update so the pin moves when patches arrive. Otherwise your pin becomes the source of your exposure.
Why this stretches the exposure window
The rebuild that did not fix anything is a hidden loop: merge, build, deploy, rescan, find the flaw again. Each loop is a day or more. A scan step between build and deploy breaks the loop early.
Try it yourself
Open the container scan demo and compare findings before and after a base image change.
Click through it at your own pace, or open it full screen.
Safeguard offers container image scanning and policy gates to block an image that still carries a flagged package. Try a free scan at gold.safeguard.sh/scan.
Quick check
Does the no-cache flag update my base image?
No. Per Docker's guidance it re-runs build steps but does not pull a fresh base image. Use the pull flag for that.
How do I know the fix shipped?
Scan the new image and verify the digest of the running container.
Sources
Last reviewed: 19 October 2026.
