Several beliefs about container scan fixes sound reasonable and are wrong: that deleting a package in a later step removes it, that updating the OS fixes app dependencies, that a new tag means a new image, and that a higher version number always means patched. The table gives the short version and the sections give the evidence.
| Myth | Fact |
|---|---|
| Deleting a package in a later Dockerfile step removes the finding | Earlier layers still hold it |
| Updating the OS fixes language packages | They are managed separately |
| A tag always points to the same image | Tags move, digests do not |
| A lower upstream version means unpatched | Distributions backport fixes |
| A Go binary is fixed by an OS update | It needs a rebuild |
| Patching a running container fixes the image | It changes one container |
Myth: deleting in a later step removes it
The OCI layer specification describes layers as changesets applied in order, with deletions represented in the later layer. The earlier layer still contains the content. A scanner that reads every layer can still see it. Install and clean in one step, or use a multi-stage build. See what to do with a package you do not use.
Myth: updating the OS fixes language packages
OS packages come from the system package manager. Language packages come from your lockfile and live in their own directories. The Debian Python policy, for example, reserves system directories for packages from the OS, and pip installs elsewhere. See does patching the OS fix app dependencies.
Myth: a tag is a fixed image
Docker's build guidance page notes that a tag can resolve to a different underlying version over time and recommends the pull flag to get a fresh base. Digests identify content. Scan and deploy by digest. See can you rely on a tag.
Myth: an old looking version is unpatched
Debian policy describes stable updates as the same upstream version with a revision suffix such as plus deb12u1. The fix lives in the revision. Compare the whole string with the package manager, not the upstream number. See what deb12u1 means.
Myth: a Go binary follows the OS
The Go documentation says go version reports the Go version used to build a binary, and govulncheck reads build information from the binary itself. The fix is a rebuild with a patched toolchain. See Go standard library findings.
Myth: patching a live container fixes the image
Docker documents images as immutable snapshots and recommends rebuilding regularly. A package upgrade run in a live container changes its writable layer alone, and it is lost when the container is replaced.
Why myths persist
Each one is true in a simpler setting. Deleting works on a normal filesystem. Updating the OS does update OS packages. Tags often do stay put for a while. The layered, immutable nature of images is what breaks the intuition.
Quick check
Which myth costs the most time in practice?
Believing a tag is stable. Teams rescan a tag, see different results and lose a day looking for the cause.
Is there any case where deleting in a later step helps?
It stops the file being used at run time, but it does not remove it from the earlier layer or the image size.
Sources
- OCI image layer specification
- Docker build guidance
- Debian Python Policy
- Debian Policy, Version field
- Go command documentation
Last reviewed: 19 October 2026.
