Short answers first: the fixed version is the first patched release, base image findings are cleared by rebuilding on a fresh base, OS and application packages have different owners, and you rebuild rather than patch a running container. The eight questions below expand each point with links.
1. What is the fixed version?
The first package version the vendor says carries the patch. Compare with the package manager's rules, not by eye. Details: what the fixed version means.
2. Why is a package flagged when its version looks new?
Either the vendor has not shipped the fix for your release, or the scanner is matching on upstream numbers and missing a backport. Check the vendor's status. See backported fixes.
3. Why does one CVE appear several times?
A source package builds several binary packages, and each is listed. Count by source package. See why one CVE lists several packages.
4. Who fixes an OS package versus a language package?
| Package type | Where it comes from | Who changes it |
|---|---|---|
| OS package | The base image or an install step | Platform or app team, via rebuild |
| Language package | Your lockfile | App team, via dependency update |
| Compiled binary | Your build | App team, via rebuild with a patched toolchain |
Updating the OS does not change language packages. See does patching the OS fix app dependencies.
5. Can I patch a running container?
You can, but the change lives in that container's writable layer and disappears when it is replaced. Docker's guidance is that images are immutable snapshots and should be rebuilt regularly with updated dependencies. So rebuild.
6. Why did the scan change when I did not change the image?
New advisories are published all the time, and vendor data changes. The same image can gain findings. See why an unchanged image gains vulnerabilities.
7. What if there is no fix?
Check the vendor status and notes, assess whether the code is reachable, add controls and record an exception with an expiry. See no fix available.
8. Does a clean scan mean the image is safe?
No. A scan matches known issues in known packages. It does not find unknown flaws, misconfiguration or malicious code that has no advisory. See what container scanning cannot see.
A habit that helps
Keep the digest, the report and the decision together for each release. It turns every future question into a lookup instead of an investigation.
Where Safeguard fits
Safeguard's SBOM and dependency scanning and reachability analysis support these decisions. Free scan: gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Find the package, installed and fixed columns.
Quick check
Which of the eight questions causes the most wasted work?
Usually the duplicate rows question. Counting by source package or unique CVE removes the double handling.
Where do I start with a long report?
Group by layer, fix the shared base first, then work what remains by reachability.
Sources
Last reviewed: 19 October 2026.
