A Red Hat host running httpd-2.4.6-99.el7_9.x86_64 has had the fix for a critical Apache CVE backported into its package for over a year, yet the vulnerability scanner opens a new finding for it on every cycle. The sysadmin closes it as a false positive, the auditor reopens it three months later because the version string in the report still reads 2.4.6, and nobody has a document that settles the argument. This is a backported patch false positive, and on any fleet of RHEL, Debian or SUSE servers it is one of the largest sources of wasted remediation and audit time. The fix is not to argue with the scanner; it is to know exactly which check produced the finding and what evidence overrides it.
How enterprise distros backport fixes while keeping the upstream version string
Upstream projects like Apache httpd, OpenSSL and the Linux kernel move forward by releasing new minor and major versions. Enterprise distributions do not follow that model for their supported lifecycle. Red Hat, Debian and SUSE each commit to years of support for a single major release of a package, and rebasing that package to a new upstream version mid-cycle would change its ABI, its default configuration, and its behavior in ways that break the applications running on top of it. Instead, distro maintainers cherry-pick the specific security-relevant commit out of the upstream fix and apply it as a patch on top of the version they already ship, then rebuild under the same upstream version number.
The result is a package whose upstream version field never changes while its distro-specific release field climbs every time a fix lands. On RHEL 7, rpm -q httpd can report httpd-2.4.6-99.el7_9.x86_64 years after upstream Apache abandoned the 2.4.6 line entirely; the 99.el7_9 portion is the actual patch level, and it has absorbed dozens of individual CVE fixes. Debian does the same thing with a suffix like 2.4.38-3+deb10u9, where deb10u9 marks the ninth security update issued for that package in the Buster release. SUSE packages carry an equivalent build suffix, for example apache2-2.4.51-150400.3.29.1, where the trailing segment tracks maintenance updates. In every case, the upstream version token is frozen for compatibility and the real patch history lives in a field most tools never look at.
Why version-banner checks on RHEL, Debian and SUSE produce phantom CVEs
A scanner running in unauthenticated or network mode has no visibility into the package database. It sees what the service exposes over the wire: an HTTP Server header, an SSH banner, a TLS certificate’s software hint. Those banners report the upstream version string because rewriting them would break clients and monitoring tools that parse them, and because the string itself was never meant to communicate patch level. When a scanner matches that banner against the NVD CPE dictionary, it is comparing cpe:2.3:a:apache:http_server:2.4.6 against a vulnerable range such as 2.4.0 through 2.4.53, and 2.4.6 falls inside that range regardless of how many backports have been applied on top of it.
This is why a RHEL 7 host can accumulate dozens of open findings for CVEs published years after 2.4.6’s nominal release date, every one of them already fixed by the distro’s maintenance stream. The CPE dictionary was built for upstream version comparison, not for distro release-tag comparison, so it cannot see the fix. Any check that stops at the banner or the CPE match, rather than the actual installed package release, will keep reopening tickets for issues that were closed on day one of the maintenance update.
Reading the vendor changelog and package release field to prove the fix is present
The proof that a fix is present lives in two places: the package’s own changelog and the vendor’s published advisory. On an RPM-based system, rpm -q --changelog httpd | grep -i CVE-2017-9798 returns the changelog entry where the maintainer recorded that the CVE was addressed, along with the date and the NVRA of the build that fixed it. Pairing that with rpm -q --qf "%{VERSION}-%{RELEASE}n" httpd gives the exact installed release string to compare against the advisory. Red Hat publishes that mapping directly: an erratum such as RHSA-2017:2811 on the Red Hat customer portal lists the exact fixed package NVRA for every affected channel, so the changelog entry and the erratum should agree.
Debian systems keep the same information in /usr/share/doc/<package>/changelog.Debian.gz. Running zcat /usr/share/doc/apache2/changelog.Debian.gz | grep -i CVE-2017-9798 shows the entry, and the Debian Security Tracker records the fixed version per suite for independent confirmation. On SUSE, rpm -q --changelog apache2 serves the same purpose, cross-checked against the SUSE-SU advisory number via zypper patch-info. The rule that holds across all three distros: the version string alone proves nothing, but the changelog entry citing the CVE ID, matched against the vendor’s own advisory for the fixed NVRA, is evidence a scanner report cannot override.
Which scanner checks are banner-based and which are package-database-based
Most mainstream scanners ship two different detection paths for the same vulnerability, and only one of them is trustworthy on a backporting distro.
| Scanner | Network / unauthenticated path | Authenticated / local path |
|---|---|---|
| Nessus | HTTP Server header or service banner regex matched against generic CPE ranges | Red Hat / Debian / SuSE Local Security Checks plugin families run rpm or dpkg queries over SSH and compare NVRA against advisory data |
| OpenVAS / Greenbone | “Services” NVT banner detection plus CPE lookup | Notus scanner performs an offline rpm/dpkg database compare against synced vendor OVAL and advisory feeds |
| Qualys | Service banner heuristic driving QIDs flagged as remote-detectable | Authenticated QIDs read the installed package inventory and compare it against the QID’s vendor-advisory fixed-version logic |
The practical problem is that both paths often stay enabled at once. A shop that runs periodic unauthenticated scans against internet-facing services for exposure monitoring, in addition to authenticated internal scans for compliance, will see the same CVE closed by one plugin and reopened by the other on the same host. Any platform that aggregates results across a large scanner roster, the kind of consolidation covered under scanner integrations, needs a rule for which of the two findings wins when they disagree, because deduplication logic that just matches on CVE ID will otherwise flip the same host between open and closed every cycle.
Configuring scanners to prefer local package evidence over remote banners
Each scanner has a concrete switch for this, and none of them are set correctly by default.
- Nessus: enable the “Red Hat Local Security Checks”, “Debian Local Security Checks” and “SuSE Local Security Checks” plugin families, and make sure the credentialed scan target has an SSH account that can read the package database. Findings whose evidence field only cites a service banner should be tagged advisory-only rather than counted toward SLA.
- OpenVAS / Greenbone: switch the scan config to rely on the Notus product-based detection path, keep the SCAP and vendor OVAL feeds current with
greenbone-feed-sync --type GVMD_DATA, and disable the generic “Services” banner NVTs for any target that is already scanned with credentials. - Qualys: run an authenticated scan with a Unix auth record so package-based QIDs fire, and exclude the “potential vulnerability” QID category from automated closure SLAs until it is manually confirmed.
The general threshold to apply during triage, regardless of scanner: a finding whose only supporting evidence is a raw banner string or a generic CPE match gets routed for manual verification before it counts against a deadline; a finding backed by a package-database or OVAL comparison can be trusted to auto-open or auto-close. Platforms that ingest output from multiple scanners, such as SITEY, can apply exactly this rule inside their triage phase, so a CVE surfaced only by a banner check is held for evidence review instead of being pushed straight into a remediation queue built for confirmed findings, a distinction that matters most in the part of the pipeline covered by vulnerability lifecycle tracking.
A repeatable verification procedure for auditors who challenge the closure
When an auditor reopens a finding that the operations team already closed, the fastest way to end the disagreement is a fixed sequence that produces the same answer every time:
- Capture the original finding exactly as reported: the CVE ID, the plugin or QID number, and the raw evidence field the scanner used to flag it.
- Query the installed package directly on the host:
rpm -q --qf "%{NAME}-%{VERSION}-%{RELEASE}n" <package>on RPM systems, ordpkg-query -W -f='${Package} ${Version}n' <package>on Debian-based systems. - Retrieve the vendor’s advisory for that CVE, RHSA/erratum, DSA from the Debian Security Tracker, or SUSE-SU, and confirm the fixed NVRA or version listed there matches or is older than what is installed.
- Extract the changelog entry citing the CVE ID from
rpm -q --changelogorchangelog.Debian.gz, so the fix is documented twice: once by the vendor and once by the package itself. - Bundle the command output, the advisory link and the changelog excerpt into the ticket, and record the disposition as backported and not vulnerable, with an expiration date tied to the distro’s end-of-life for that major version, since a backport is only guaranteed for the support window, not forever.
- Re-run the scanner in authenticated mode against the same host and confirm the local-check plugin independently reports the CVE as fixed. A second scanner-generated artifact, not just manual shell output, is what most audit frameworks expect before they accept a closure.
This is the same sequence that belongs in the compliance record itself, not just the ticket. A platform whose retest and closure phase re-checks the specific finding rather than trusting an exit code keeps this evidence attached to the CVE it applies to, so an auditor working from a report under compliance mapping for ISO 27001 or PCI DSS sees the package query and the advisory link the analyst actually used, instead of a bare “resolved” status with no supporting artifact. Platforms that automate this phase, such as SITEY, re-test the specific finding against local package evidence instead of relying on the same banner check that raised the false positive in the first place, which is the only way to keep a backport-heavy fleet from cycling the same closed CVE through the queue every quarter.
About SITEY
SITEY is an autonomous vulnerability management platform. It discovers, validates, prioritizes, remediates and re-tests vulnerabilities through an eight-phase automated pipeline, unifying output from 17 integrated scanners. SITEY is self-hosted: it runs in your own infrastructure and your findings are stored there. Outbound connections are limited to licence activation and the optional services you enable, such as an AI provider, CVE enrichment and patch catalogues. Pricing is 599 USD per month or 5,999 USD for a perpetual lifetime license. See pricing or how the platform works.