The fixed version in a container scan finding is the first package version that your operating system vendor says contains the patch for that CVE. If the version installed in the image is lower, the finding is open. If it is equal or higher, the image already has the fix.
What the column actually claims
A scan row usually shows three version fields: the package name, the installed version and the fixed version. The installed version is read from the package database inside the image layers. The fixed version comes from a vulnerability feed, ideally the one your distribution publishes, because distributions often patch an older upstream release instead of moving to a new one.
That last point matters. A fixed version of 1.1.1w-0+deb11u2 is a statement about a Debian package build, not about the upstream project's release number. Reading it as "upgrade to upstream 1.1.1w" will mislead you.
How versions are compared
Do not compare version strings by eye. Debian policy defines the format as an optional epoch, then the upstream version, then a Debian revision, and says the package manager splits the string at the last hyphen. Epochs compare first, as numbers. Then the upstream part, then the revision. A tilde sorts before anything, even the end of a part, so 1.0~rc1 is lower than 1.0.
For stable updates, the policy describes suffixes in the form debNuX, where N is the Debian release number and X counts the stable uploads. A +deb12u2 suffix means the second stable update on the same upstream version, built for Debian 12. See also what the epoch prefix means.
You can ask the package manager itself. Inside the image, dpkg-query can print the installed version, and dpkg --compare-versions answers "is A lower than B" using the real rules.
docker run --rm --entrypoint dpkg-query myimage@sha256:abc123 -W -f='${Package} ${Version}\n' openssl
dpkg --compare-versions 3.0.11-1~deb12u1 lt 3.0.11-1~deb12u2 && echo "installed is lower"
What to do for each situation
| Situation | What it means | Action |
|---|---|---|
| Installed lower than fixed | Patch exists, image does not have it | Rebuild on a fresh base, or upgrade the package in the build |
| Installed equal or higher | Already fixed | Check the scanner feed is current, then close |
| Fixed version blank | No fix published for your release | Use the no-fix path, see image vulnerability has no fix |
| Fixed version is in a newer release alone | Your OS release may not get it | Plan a base image move or record an exception |
| Version looks old but scanner says fixed | Likely a backport | See backported fixes explained |
Getting the fix into the image
An image is a snapshot. Docker's own build guidance says images are immutable and should be rebuilt regularly with updated dependencies, and that the pull flag makes the build fetch a newer base image instead of using a cached copy. So the usual route is rebuild with a pull, then rescan the new digest, rather than patching a running container. The trade-offs are covered in apt upgrade or rebuild.
After the rebuild, confirm the installed version moved. A rebuild that hits a stale cached layer can leave the old package in place.
Where Safeguard fits
Safeguard's SBOM and dependency scanning reports installed and fixed versions per component, and reachability analysis helps decide which open findings deserve the first rebuild. You can run a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Look at the installed and fixed version columns on a finding.
Quick check
Is a blank fixed version the same as "not vulnerable"?
No. Blank usually means no fix has been published for your release. The package may still be affected.
Can I compare versions with a spreadsheet sort?
Not safely. Epochs, tildes and revisions follow package manager rules. Use the package manager's own comparison.
Sources
Last reviewed: 19 October 2026.
