Backported Security Fixes Guide: Why Version-Based Scanners Misreport Patched Linux Packages and How to Prove Status

A fully patched Red Hat, Debian or Ubuntu server can still show dozens of "critical" findings because the scanner compared the package's upstream version number with a CVE's affected range and ignored the fix the distribution backported. The opposite also happens: a scanner trusts a distribution's "not affected" or "fix deferred" status and the team assumes a risk is closed when it is not. This guide explains how distribution backporting works, why version-only matching misreports it, which data sources give the real status, and how to prove a package's status to an auditor or a customer. It is written for vulnerability management teams, Linux platform engineers and anyone who has to answer a penetration test or questionnaire that says "OpenSSH 8.9 is vulnerable".

Key takeaways

• The version string is not the patch level. Enterprise distributions apply upstream security fixes to the version they shipped, so the upstream version stays the same and only the package release part changes.
• Use the distribution's own advisory data. Red Hat CSAF and VEX, the Debian Security Tracker, Ubuntu's CVE tracker and OVAL feeds record per-release status that version ranges from NVD cannot.
• Banner-based network findings are the worst offenders. A remote scanner that reads "OpenSSH_8.9p1" from a banner has no way to see backported patches; verify on the host.
• Proof is the advisory plus the installed package version. Match the exact installed NEVRA or Debian version to the fixed version in the vendor advisory, and keep the evidence.
• False negatives matter too. "Fix deferred", "will not fix" and end-of-support releases are real exposure; distribution status is the truth about the package, not a risk acceptance.

What backporting is and why distributions do it

Red Hat describes backporting as taking a security fix from the latest upstream version of a package and applying it to the older version it distributes, after isolating the fix from other changes and checking it has no side effects. The reason is stability: customers get automated updates without the compatibility breaks a new upstream version would bring. Red Hat's example is PHP, where moving from 5.3 to 5.4 to obtain a fix could have broken applications, so the 5.3 packages were patched instead. Red Hat states plainly that "just looking at the version number of a package will not tell them if they are vulnerable or not", and that scanning tools which judge by version alone produce false positives.

Debian's security FAQ says the same thing in Debian terms: security fixes are backported to the version shipped in the stable release so that a release does not change unexpectedly, and moving to a new upstream version is considered only when a fix cannot be backported. Ubuntu, SUSE, Amazon Linux and Alpine follow broadly the same model for their supported releases, though some packages (browsers are the usual example in Red Hat's text) are updated to new upstream versions instead.

Reading the version string

The part of the version that carries the patch is not the part a scanner reads from a banner or an NVD range.

Debian Policy defines the comparison: the epoch is compared first, numerically, then the upstream version, then the Debian revision, alternating between lexical and numeric segments, with a tilde sorting before everything so that 1.0~beta1 is lower than 1.0. Any tool that compares distribution versions must implement these rules (or the RPM equivalent); a simple string or semantic-version comparison gets them wrong. The example strings above illustrate the format and are not tied to a particular advisory.

Why scanners misreport

Trivy's documentation is a clear statement of the right behaviour: for packages installed by the OS package manager it consumes only the distribution's advisories (Red Hat security data, the Debian Security Tracker, the Ubuntu CVE Tracker and others), because vendors backport upstream fixes and the fixed version can differ from upstream; its example is a Red Hat package patched in a release whose upstream version is still inside the CVE's affected range. It also prefers the distribution's severity over NVD's. Debian adds a caution of its own: it does not use CVSS for triage, so a scanner's severity does not reflect Debian's assessment, and inaccurate scanner data should be reported to the scanner vendor, not to Debian. See the Trivy Guide and the CVE, CWE and CPE Guide.

Authoritative status sources by distribution

Red Hat announced in 2023 that CSAF replaced CVRF, that OVAL v1 was retired, and that OVAL v2 support would continue until the end of 2024, positioning CSAF VEX as the replacement because OVAL cannot express non-RPM container content well. Its VEX files record one of four statuses per product and component. Check Red Hat's security data page for the current state of OVAL v2 before building anything new on it. Ubuntu's OVAL page documents scanning a host with oscap oval eval --report report.html com.ubuntu.$(lsb_release -cs).usn.oval.xml. See the VEX Guide, the CSAF Security Advisories Guide and the OpenSCAP Linux compliance scanning guide.

How to prove a package's status

When a finding is disputed, the answer is evidence from the host and from the vendor, not an argument about version numbers.

1. Identify the package that provides the component: a banner says "OpenSSH"; the host says which package. Use rpm -qf or dpkg -S on the binary, then record the full installed version (rpm -q or dpkg-query -W).
2. Look up the CVE in the distribution tracker: Red Hat CVE page, Debian Security Tracker or Ubuntu CVE page, for the exact release (RHEL 9, bookworm, jammy). Note the status and the fixed package version.
3. Compare with the distribution's rules: installed version equal to or greater than the fixed version, compared with rpmdev-vercmp or dpkg --compare-versions, not by eye.
4. Check the changelog as supporting evidence: Debian's FAQ suggests apt-get changelog package-name and finding the entry that announces the fix; on RPM systems rpm -q --changelog package lists CVE references for most security updates.
5. Confirm the running process uses the patched code: a fixed library on disk does nothing for a daemon still running the old one. Check for services needing restart (needs-restarting on RHEL, needrestart on Debian and Ubuntu) and kernels needing a reboot.
6. Record the evidence: CVE, host, installed version, fixed version, advisory ID and URL, date checked. Where you issue statements to customers, express them as VEX. See the How to Read a CVE Advisory Guide.

Fixing the process, not just the finding

• Use authenticated, distribution-aware scanning: configure the scanner to use credentialed checks and distribution advisory feeds for Linux hosts, and treat unauthenticated banner findings on distribution packages as leads to verify, not as findings. See the Vulnerability Prioritisation Guide.
• Make OS detection correct: distribution feeds only work if the scanner knows the exact release; derivative distributions and minimal container images are often misidentified.
• Suppress with a reason, not a blanket rule: record each false positive as a suppression tied to the CVE, package and fixed version, so it expires when the package changes, rather than ignoring a CVE across the estate.
• Feed corrections back: report wrong scanner logic to the scanner vendor, as Debian asks.
• Separate OS packages from everything else: backporting only covers distribution packages. A pip, npm or Java library vendored in an application, or software installed from a tarball, follows upstream versions and needs upstream advisories.

Small and large organisations

Small teams get most of the value by switching Linux scans to authenticated mode and keeping a short evidence log for disputed findings. Large estates should ingest distribution CSAF, VEX and OVAL data centrally, reconcile scanner output against it automatically, and report "distribution-confirmed fixed" as a separate state in vulnerability dashboards so SLA metrics are not polluted by false positives.

Containers, images and SBOMs

The same problem appears in container scanning, often more sharply, because images are scanned in bulk and results feed release gates.

• Base image packages: an image built on a RHEL UBI, Debian or Ubuntu base carries distribution packages with backported fixes. Image scanners must read the package database inside the image (the RPM database or /var/lib/dpkg/status) and apply the matching distribution feed. Red Hat states that its VEX files also cover non-RPM content in container images.
• Distroless and minimal images: some minimal images strip the package database, so the scanner falls back to file or binary heuristics and upstream version matching. Prefer base images that keep package metadata, or that publish an SBOM with distribution package identifiers.
• SBOM identifiers: an SBOM that records components as package URLs with the distribution and full version (for example pkg:rpm/redhat/... or pkg:deb/debian/...) lets a downstream consumer apply the right advisory data. One that records only "openssl 3.0.7" forces version-range matching and recreates the false positives. See the SBOM Guide.
• Release gates: a gate that fails builds on NVD-range findings for OS packages blocks releases for issues the distribution has already fixed. Gate on distribution-confirmed status, and record exceptions as VEX so the reasoning travels with the image.

False negatives: when the distribution says no fix

Distribution status is accurate about the package, but it is not a statement that your risk is acceptable.

• Fix deferred or postponed: Ubuntu's "Vulnerable, fix deferred" and Debian's postponed or no-DSA notes mean the package remains vulnerable, usually because the distribution judged the issue minor. Your exposure may differ; decide with compensating controls.
• Ignored or will not fix: Ubuntu marks packages Ignored when, for example, they are no longer supported or a fix would break other functionality. Scanners with "ignore unfixed" options, such as Trivy's --ignore-unfixed, hide these findings entirely.
• End of standard support: once a release leaves standard support, many packages stop receiving fixes unless you have extended support. See the Ubuntu LTS End of Standard Support guide.
• Not yet assessed: "Needs evaluation" and "Under Investigation" are unknowns; NVD backlogs can delay upstream data too. See the CVE Programme and NVD Backlog Guide.

Detection and measurement

• False positive rate on Linux findings: share of findings closed as "distribution-confirmed fixed".
• Share of Linux hosts scanned with credentials and distribution advisory feeds.
• Number of open findings in deferred, ignored or unfixed status, with an owner and a compensating control.
• Hosts with patched packages on disk but services or kernels still running old code.
• Median time to resolve a disputed finding with recorded evidence.
• Number of hosts on releases past standard support.

Framework mapping

Common failure patterns

• Upgrading to upstream to silence a scanner: replacing a distribution package with a source build to satisfy a version check removes the host from the distribution's security updates and creates a real, untracked risk.
• Arguing from the banner: both the tester and the defender cite "OpenSSH 8.9p1" without ever checking the installed package release.
• Blanket CVE suppression: suppressing a CVE everywhere because it was a false positive on one release hides it on hosts where it is real.
• Patched on disk, vulnerable in memory: services not restarted after a library update keep running old code.
• Treating "not fixed by the distribution" as closed: deferred and ignored statuses quietly drop out of reports when ignore-unfixed options are on.
• Applying distribution logic to application dependencies: language packages and vendored libraries do not get backports.

Practitioner checklist

• Scan Linux hosts and images with credentials and distribution advisory feeds, not banners or NVD ranges alone.
• Confirm the scanner identifies each distribution and release correctly.
• For disputed findings, record installed version, fixed version, advisory and date checked.
• Compare versions with dpkg or RPM tooling, never by eye or as semantic versions.
• Check that services and kernels were restarted after security updates.
• Track deferred, ignored and unfixed statuses as open risk with compensating controls.
• Scope suppressions to CVE, package and version, so they expire on change.
• Publish VEX statements for products you ship, citing the distribution's status.

Standards and references

• Red Hat: Backporting Security Fixes
• Debian: Security FAQ
• Debian: Policy Manual, Control files and their fields (Version)
• Ubuntu: About CVE status
• Ubuntu: OVAL data
• Red Hat: The future of Red Hat security data
• Red Hat: VEX files now available
• Trivy: Vulnerability scanning documentation

Related NHI Mgmt Group resources: VEX Guide · CSAF Security Advisories Guide · Patch Management Guide · Risk-Based Vulnerability Management Guide · Trivy Guide