Confirm a fix with four checks: the image digest changed, the installed package version is at or above the fixed version, the build used a fresh pull when needed, and a rescan of the new digest no longer lists the finding. A passing pipeline alone is not proof.
Why a rebuild can silently fail
Docker caches build steps. Its cache documentation explains that when a step changes, that layer and all later layers are invalidated, but a step whose instruction text is unchanged can be reused. A line that runs a package install looks identical today and next month, so it may be served from cache with old packages inside. The build guidance page addresses this with two flags: pull, to fetch a newer base, and no cache, to rerun every step.
So the build can succeed, the tag can move, and the vulnerable package can still be there.
The four checks
1. The digest changed
Tags move. Digests identify content. Record the digest before and after.
docker buildx imagetools inspect myapp:prod | head -5
If the digest is the same, nothing was rebuilt or pushed.
2. The installed version meets the fixed version
Read the version from the image itself, not from the Dockerfile.
docker run --rm --entrypoint dpkg-query myapp@sha256:newdigest -W -f='${Package} ${Version}\n' libssl3
Then compare with the fixed version from the finding using the package manager's comparison, as in what the fixed version means. For a Go binary, run go version -m on the file. For language packages, check the lockfile in the image and the installed metadata.
3. The build really pulled fresh inputs
Look at the build log for the base image digest, or build with the pull flag in CI. For repeatable builds that pin by digest, bump the pin on purpose, as covered in pin base images by digest.
4. A rescan of the new digest
Scan the exact digest you will deploy, not a tag. A rescan confirms the finding is gone and shows whether the rebuild brought in new ones. Newly published advisories can add findings to an unchanged image; see why an unchanged image gains new vulnerabilities.
Record the evidence
Keep a small record per fix: old digest, new digest, finding id, installed and fixed versions, scan date and who confirmed. This answers an auditor or a customer without a rerun, and it is cheap. Retention guidance is in how long to keep container scan evidence.
When the finding persists
| Symptom | Likely cause |
|---|---|
| Same digest | Build or push did not run |
| Version unchanged | Cached install layer or pinned base |
| Version fixed, finding stays | Scanner data lag, or a second copy of the package elsewhere in the image |
| New finding appears | New advisory, or a newer base brought a new package |
Where Safeguard fits
Safeguard's SBOM and dependency scanning gives a component inventory per image that you can diff between builds, and its compliance and evidence automation helps keep the record. Free scan: gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Watch how a finding changes state after a new scan.
Quick check
The tag points to the new build. Is that enough?
No. Tags can move or be cached. Check the digest and the installed version.
Should I always build with the no cache flag?
Not always. Use it when a cached install step may hold old packages. Use the pull flag more often.
Sources
Last reviewed: 19 October 2026.
