Linux distributions track many vulnerabilities by source package, not by the installable binary package. A container or host scan has to map each installed binary back to its source before it can match a record. If the mapping is missing, a vulnerable library can look unaffected.
Source versus binary, in plain terms
The Debian FAQ describes two kinds of package. Binary packages are the installable .deb files that hold executables, configuration and documentation. Source packages hold the code and build instructions, and they cannot be installed directly. They are unpacked and built to produce the binary packages.
The same source can produce several binaries. A library might ship a runtime package, a development package and a tools package, all built from one source. A vulnerability in the code affects all of them, even though the names differ.
Why the distinction affects accuracy
The Debian security tracker accepts CVE names, bug numbers and package names as search terms, and its views are organized around packages. When a scanner reads the package database inside an image, it sees binary names and versions. To use a distribution's advisory data it needs the matching source name and source version.
Where does it go wrong?
- The binary name differs from the source name, so a string match returns nothing.
- The binary version differs from the source version, so a range check compares the wrong number.
- Several binaries share one source, so a finding appears for one but not the others.
Well built scanners handle this, and the status fields in the distribution data tell them what to do. The point for a buyer is to ask how it is handled, not to assume.
A quick test on your own image
- Pick a base image you can reproduce. Run a scan and save the output.
- Choose three installed packages, ideally one whose name is clearly different from its source. Use the package manager's own query to see the source name.
- Look up each source in the distribution's security tracker and note any recorded issues and their status.
- Check that your scan lists the same issues against the same packages, or shows a reason where it does not.
A difference is not always a bug. Distributions sometimes mark an issue as not requiring an advisory or as fixed in a patched version that keeps the old upstream number. For that second case see how to judge a fixed version or a backported fix.
What to ask a vendor
- Which operating system families does the scan match against, and which advisory source does it use for each?
- Does it map binary to source packages, and what does the report show when mapping fails?
- How does it treat distribution statuses such as unfixed or ignored?
Safeguard's container image scan lists operating system packages alongside language packages, and you can see what a result looks like in the demo below. The free scan is at https://gold.safeguard.sh/scan.
Try it yourself
Open the container image scan demo and compare the operating system findings with the application findings. Look at the package name and version columns.
Click through it at your own pace, or open it full screen.
Quick check
Is a binary package the same as a source package?
No. The binary is the installable file. The source is the code and build instructions that produce one or more binaries.
Why would a scanner need the source name?
Distribution vulnerability data is often organized by package, so the scanner has to connect each installed binary to the record that covers it.
Sources
Last reviewed: 19 October 2026.
