Why does an OS package scan call a Debian host vulnerable after the distro backported the fix?

This is the classic false positive in operating-system package scanning, and it is worth understanding precisely because the argument usually happens in front of a customer rather than in a terminal. ## What backporting is A stable distribution release promises that packages do not change behaviour for the life of the release. When a security flaw is found in a component, taking the newest upstream release would break that promise, so the distribution maintainer extracts the security patch and applies it to the version already shipped. The package version then carries the original upstream number plus a distribution revision - something of the form `1.1.1n-0+deb11u5`, where the part before the dash is upstream and everything after it belongs to the distribution. The upstream number is deliberately unchanged, because upstream did not release anything. ## Why matching breaks An upstream advisory says: affected from some version, fixed in a later one. That range is expressed in upstream's version scheme, and it has no vocabulary for *this distribution applied the patch at its own revision 5*. A matcher that parses the version string, takes the upstream component and evaluates the upstream range concludes that the host is affected. It is applying the rule correctly to data that cannot express the situation. The reverse error also exists and is worse: a distribution may leave a flaw unpatched on purpose - marked as not affected by how it builds the package, or as will-not-fix for that release - and a naive upstream match can miss it if a version number happens to sit outside the upstream range. ## Where the truth lives Only the distribution knows what it patched, so the distribution publishes it: a security advisory per fix, and machine-readable definitions that state, per release and per package, which revision fixed which flaw and which flaws are known and deliberately not fixed. That data is keyed to the distribution's own version scheme, so the comparison becomes exact: does the installed revision sort at or above the fixed revision for this release. This is the same principle as preferring an ecosystem-native record for a language dependency - match with the feed that speaks the same versioning language as the artifact you are matching against. ## The operational fix Split matching by component class. Installed OS packages match against the distribution feed for the exact release, including its end-of-life status. Language dependencies match against their ecosystem feeds. A single generic upstream source applied to both is how an estate accumulates hundreds of unfixable findings, and unfixable findings are how teams learn to ignore the report. Second, make the distribution release explicit in the inventory. The same package revision means different things on two releases, and a matcher that does not know which release it is looking at cannot use the distribution data at all. ## The audit dimension The reason this question is asked at senior level is rarely the mechanics. It is that the disagreement surfaces in a customer security review: their scan of your image reports a critical, your remediation record says patched, and the credibility of your whole vulnerability programme is now the subject. What you owe them is evidence, not reassurance: the installed package revision, the distribution advisory that names that revision as the fix for that flaw, and a one-paragraph explanation of backporting. That is a verifiable claim they can check against a public source. A screenshot of your own tool saying zero findings is not - it asks them to trust your tool over theirs, which is exactly the trade they are not going to make. It is also worth saying plainly which cases are genuinely bad news, because a reflexive *that is just a backport* is its own failure mode. The finding is real when the installed revision predates the distribution's fixed revision; when the release has reached end of life and no longer receives fixes; when the distribution has explicitly declined to fix it for that release; or when the binary was installed outside the package manager, in which case the package database is describing something that is not what is running. Check those four before you write the word backport in a customer response. ## The general lesson A version string is not a fact about content - it is a label whose meaning is set by whoever publishes it. Wherever a publisher patches an artifact and keeps the version, the fix is visible only in that publisher's own advisory data. Choosing the right advisory source for each class of component is not tuning; it is what makes the output mean anything.