One CVE can appear on several rows because a distribution builds many installable binary packages from one source package. The vulnerable code is in the source, so every binary package built from it is flagged. Fix it once, by updating that source package's binaries together.
Source package versus binary package
Linux distributions like Debian ship software as source packages. A source package is built into one or more binary packages, which are the .deb files that land in your image. A library source package might produce a runtime library, a development package and a command line tool.
Vulnerability trackers record problems against the source package. A scanner reading the image sees binary packages in the package database, maps each back to its source, and reports a row per binary. So one OpenSSL issue can show a row for the library and another for the tool, and a different one for a related package built from the same source.
What Debian says to do
The Debian security FAQ states that announcements mention the source package where the flaw was present, and that you should update all the binary packages from that source package. It also points to the packages site, where you can list the binary packages for a given source and release.
That guidance maps directly to scan results. When three rows share a CVE and a source name, you have one fix, not three.
How to count findings honestly
Raw row counts overstate the work and the risk. A cleaner view:
| Measure | What it counts | Use |
|---|---|---|
| Rows | Binary package and CVE pairs | Scanner output, noisy |
| Unique CVEs | Distinct vulnerability ids | Exposure view |
| Source packages | Distinct upstream sources affected | Work view, how many updates |
| Layers | Where the packages entered the image | Ownership view |
Report unique CVEs and source packages to leadership. Hand layers to the owning team. If you also feed rows into a ticketing system, group by source package or you will create duplicate tickets that close together.
Checking it inside an image
You can see the source name the package database records.
docker run --rm --entrypoint dpkg-query myimage@sha256:abc123 -W -f='${binary:Package} ${source:Package} ${Version}\n' | sort -k2 | head -30
Rows that share the second column come from one source. If their versions differ slightly, check why. A partial update is the usual cause, where one binary was upgraded and a sibling was not.
Why the siblings can lag
Sometimes a sibling binary is pinned or held back in a Dockerfile. Sometimes the base image changed one package through a security update and a cached layer kept another. The cure is the same either way: refresh the whole source family during a rebuild with a fresh pull, not one package by name. For deeper background, see what a container image layer is and grouping findings by base image.
Where Safeguard fits
Safeguard's SBOM and dependency scanning keeps component and version data you can group, and its policies can gate on unique findings instead of raw rows. Try a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Notice how components group, and imagine counting by source instead of by row.
Quick check
Are three rows for one CVE three separate fixes?
Usually no. If the rows share a source package, one update of that source's binaries closes them.
Which count should go on a leadership dashboard?
Unique CVEs and affected source packages. Rows depend on how a distribution splits its packages.
Sources
Last reviewed: 19 October 2026.
