Debian security data names the source package that was fixed, while an image lists the binary packages installed from it. A scanner has to map each binary package back to its source package and compare full Debian versions, including any epoch, to say whether a fix is present. If it skips either step, it will miss findings or invent them.
Source and binary: the basic idea
One Debian source package can produce several binary packages. A library source might produce a runtime package, a development package and a documentation package. A vulnerability in the source affects all of them, but the advisory names the source.
The Debian Policy Manual describes the Source field as identifying the source package name. In a binary package control file, it says, the source name may be followed by a version in parentheses, and the field may be left out entirely when the source package has the same name and version as the binary package. So the mapping is not always written down; a scanner sometimes has to infer it.
The public vulnerability database OSV shows the same orientation. A query for the openssl package in a Debian ecosystem returns records whose affected package carries a package URL ending in arch=source and a distro value. The record is written against the source package, with the fixed version stated for that source.
Version strings have three parts
The Policy Manual gives the format of a Debian version as optional epoch, then upstream version, then optional Debian revision. In its notation: an optional epoch and colon, the upstream version, and an optional hyphen and revision.
| Part | Meaning | Matters because |
|---|---|---|
| Epoch | A small whole number, zero if omitted | A higher epoch always sorts above a lower one, whatever the rest says |
| Upstream version | The version from the original project | Compared with Debian's own ordering rules |
| Debian revision | The packaging revision | Backported security fixes often change only this part |
The Policy Manual says epochs help when the upstream numbering scheme changes and that they must be used with care. In the Debian security tracker's own documentation there is an example entry for a package at version 4:0.7.1-7. The 4 is an epoch. A scanner that drops the epoch and compares only 0.7.1-7 would sort it wrongly against a version written with a different epoch.
Why backports make this matter
Debian often fixes a vulnerability in a stable release by patching the existing upstream version, not by moving to the new upstream version. The result is a version whose upstream part looks old but whose revision carries the fix. A tool that compares only the upstream part will say the package is vulnerable when it is not. The fixed version in the Debian data, such as a revision with a security suffix, is the one to compare against.
A worked example
An image based on Debian 12 contains a binary package built from the openssl source. The scan needs to answer one question: is the installed version at or above the version in which each CVE was fixed?
- Read the installed binary package name and version from the image's package database.
- Find its source package name and, if given, the source version.
- Look up the source package in the Debian data for the image's release.
- For each CVE, read the version in which it was fixed.
- Compare the installed version with the fixed version using Debian's comparison rules, epoch first.
- If the installed version is lower, report the CVE. If it is equal or higher, do not.
In one OSV record we fetched for a Debian 12 openssl CVE, the affected range reads as introduced at 0 and fixed at 3.0.4-1. An image carrying a much later openssl revision is above that fix and should not be reported. A tool that reports it anyway has compared versions wrongly or used the wrong release.
Questions for a vendor
- Do you map binary packages to source packages, and what do you do when the mapping is missing?
- Do you compare full Debian versions, including epochs and revisions?
- Which Debian release data do you use for an image, and how do you detect the release?
- How do you handle packages marked not affected or no advisory by the distribution?
A test you can run
Pick a Debian image with a package you know was patched by revision only. Check that your scanner does not report the CVE that the revision fixed. Then pick one that is truly behind, and check that it does. A tool that fails the first test creates false alarms. One that fails the second creates a false sense of safety.
Common mistakes
- Matching on binary package name only.
- Comparing versions as text or semantic versions.
- Ignoring the epoch.
- Using data for a different Debian release than the image.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how each finding lists the installed version next to the version that contains the fix.
Where Safeguard fits
Safeguard scans image contents and reports installed and fixed versions side by side, so you can check the comparison yourself. You can try a free scan at gold.safeguard.sh/scan.
Quick check
What is a Debian epoch?
A small whole number at the front of a version, followed by a colon. If omitted it is zero. A higher epoch sorts above a lower one regardless of the rest of the version.
Why does a patched package sometimes still look old?
Distributions often backport a fix into the existing upstream version and change only the packaging revision. The upstream number looks old, but the fix is there.
Can a CVE affect several binary packages at once?
Yes. If they are built from the same source package, a flaw in the source can affect each of them.
Sources
- Debian Policy Manual, control files and their fields
- Debian Security Tracker documentation
- OSV query API
- OSV record DEBIAN-CVE-2022-2068
Last reviewed: 19 October 2026.
