A container scan report mixes two kinds of findings: operating system packages that come from the base image, and application dependencies that come from your code. Separate them first. Base image findings are fixed by rebuilding on an updated image, while application findings are fixed by upgrading a library.
Two inventories in one report
| Type | Examples | Where it comes from | Who usually fixes it |
|---|---|---|---|
| OS packages | System libraries and utilities | The base image | Platform or image owner |
| Application packages | Language libraries | Your lockfiles | Application team |
Reading the report as one list hides that the two have different owners and different fixes. Add an owner column before anything else.
Why version formats differ
Operating system distributions package software on their own schedule and with their own version strings. The OSV schema reflects this: it has distinct ecosystems for distributions, and some ecosystem strings carry a release suffix. For example, the Ubuntu ecosystem string has a release suffix in a year and month form, and the RPM based ecosystems use RPM version ordering. So the same upstream library can show different version numbers in an OS package than in a language package.
Practical consequence: do not compare an OS package version to an upstream version number by eye. Use the fixed version the report gives for that distribution.
Steps to read the report
- Split by type. Filter OS packages and application packages into two views.
- Check the base image first. A large share of OS findings may clear with a rebuild on an updated tag of the same base image, because the distribution may have shipped patches.
- Check for packages you do not need. A shell or compiler in a runtime image adds findings and attack surface. A smaller image removes them.
- Read application findings as in any SCA report. Path, fixed version, exploit signals and reachability apply the same way.
- Rescan after the rebuild. Confirm the OS findings actually cleared.
Things that look odd but are normal
- The same CVE listed for an OS package and a language package that bundle the same code.
- A fixed version that looks older than your version, because distributions backport patches into older version numbers.
- Findings in packages marked as present but unused by your application.
Pipeline tip
Scan the image after it is built, not only the source, since the final image is what runs. Keep the scan in the build pipeline so a rebuild always comes with fresh results.
Try it yourself
Click through it at your own pace, or open it full screen. Notice which findings come from the base layers and which from your application.
Where Safeguard fits
Safeguard scans container images alongside source dependencies and applies reachability analysis to application packages.
Quick check
Why does an OS fixed version look older than mine?
Distributions often backport fixes into older version numbers. Use the fixed version given for that distribution.
Will rebuilding on the same tag fix OS findings?
Often some, if the image maintainer published an update. Rescan to confirm.
Sources
Last reviewed: 19 October 2026.
