Why Your Vulnerability Scanner Flags Patched Systems (And What Actually Closes the Finding)
A vulnerability scanner false positive usually happens because the scanner infers patch status from a version string rather than observing the patch itself. Linux distributions back-port security fixes into older package versions, so a patched server still advertises a vulnerable-looking version. Closing the finding requires vendor advisory evidence mapping the CVE to your installed package, not a rescan.
Your operations team patched the server three weeks ago. The package manager confirms it. The vendor advisory confirms it. The scan report still says the host carries a high-severity CVE, and because the scan is an ASV scan tied to a compliance deadline, the finding is not just annoying, it is blocking. Somebody now has to prove a negative.
This is one of the most common conversations we have with clients, and it is almost never resolved the way people expect. Most teams respond by rescanning, escalating to the scanning vendor, or quietly marking the finding as a false positive in a spreadsheet nobody audits. None of those close it. What closes it is evidence, assembled in a specific form, and most organizations do not have a process that produces that evidence.
The volume problem behind this is real and getting worse. Microsoft's August 11, 2026 Patch Tuesday alone addressed 421 CVEs, including CVE-2026-68820, an actively exploited use-after-free in the Windows Ancillary Function Driver for WinSock [5]. That is one vendor, one month. Meanwhile Sonatype's 2026 State of the Software Supply Chain Report found that 65% of open source CVEs carry no NVD-assigned CVSS score at all, that NVD and Sonatype scores match exactly only 4.4% of the time, and that its analysis identified 20,362 false positives, components incorrectly marked as vulnerable, alongside 167,286 false negatives, exploitable components that went unflagged [2]. The data your scanner reasons from is neither complete nor consistent.
In our vulnerability scanning and ASV engagements at Clone Systems, we consistently find that most disputed findings are correct disputes filed with the wrong evidence. The customer is right that the system is patched. The submission is a screenshot of a package manager saying "no updates available," which does not connect the installed package version to the specific CVE in question. The dispute fails, the quarter closes, and the same finding returns in ninety days.
What Actually Causes a Vulnerability Scanner to Flag a Patched System?
Three distinct mechanisms produce this result, and they need different responses. Treating all of them as "the scanner is wrong" is why the problem persists.
Back-Ported Patches and the Version String Problem
This is the most common cause on enterprise Linux. Red Hat, Ubuntu, SUSE and others maintain long-lived stable releases by taking the security fix out of a newer upstream version and applying it to the older package they ship. Red Hat describes back-porting plainly as "the action of taking a fix for a security flaw out of the most recent version of an upstream software package and applying that fix to an older version," and acknowledges directly that "some security scanning and auditing tools make decisions about vulnerabilities based solely on the version number of components they find. This results in false positives as the tools do not take into account backported security fixes" [3].
The practical effect: your OpenSSH reports itself as 8.7p1, the upstream fix landed in 9.6, and the scanner concludes you are vulnerable. Your distribution patched 8.7p1 four months ago and incremented only the package release number, which the service banner never shows. Red Hat's own recommended fix for scanner accuracy is for tools to consume OVAL definitions, machine-readable versions of the vendor's security advisories, rather than comparing version numbers [3]. Not every scanner does, and no unauthenticated external scanner can.
Unauthenticated Scanning Has to Guess
An external scan sees what your services advertise. It cannot read your package database, your patch history, or your configuration. Everything it concludes about patch level is inference from a banner, a response header, or a behavioral fingerprint. That inference is usually reasonable and sometimes wrong.
This matters for PCI in particular, because PCI DSS Requirement 11.3.2 external scanning is performed by an Approved Scanning Vendor from outside your perimeter, without credentials, by design. The same finding that would resolve instantly against a credentialed internal scan can persist for a full quarter on an ASV report. Clients are often surprised to learn that moving a workload's verification from external inference to authenticated scanning eliminates a large share of their recurring back-port findings outright, because the scanner reads the package database instead of guessing from a banner.
The Vulnerability Database Itself May Be Disagreeing
Even with perfect detection, the severity attached to a finding may be contested. Sonatype found that NVD and its own research team assigned matching severity categories only 55.7% of the time, that 61.3% of NVD scores ran higher than Sonatype's and 34.3% ran lower, and that one in seven NVD-scored CVEs diverged by three or more CVSS points [2]. NVD's median time to score an open source CVE was 41 days, with some records taking a year [2]. We have written before about what NIST's 2026 shift to risk-based NVD enrichment means for programs that assumed uniform metadata (what NIST's 2026 NVD changes mean for vulnerability management).
A finding can therefore be a true positive on detection and a false positive on severity. Those are separate disputes with separate evidence, and merging them is a common reason a submission gets rejected.
Is It Really a False Positive, or Is Your Evidence Just Missing?
Here is the distinction that matters, and it is the position Clone Systems takes on this topic: most reported false positives are not scanner errors, they are unresolved evidence problems. The scanner made a defensible inference from the information available to it. The finding stays open not because anyone disagrees with your remediation but because nobody has produced the artifact that disproves the inference.
That reframing changes what your team should do. You are not arguing with a tool. You are submitting a case.
| What teams usually submit | What it actually proves |
|---|---|
| "We patched it, here's the ticket" | A change was made. Not which CVE it addressed. |
| Screenshot of package manager showing no updates | The system is current against its repository. Not that this CVE is fixed in the installed version. |
| Upstream version number of the software | Only relevant if you are not on a back-porting distribution. |
| Vendor advisory naming the CVE and the fixed package release, plus the installed package release | The specific vulnerability is remediated on this specific host. |
Only the last row closes a finding. The first three are true statements that answer a different question.
What Evidence Actually Closes a Disputed Scan Finding?
For PCI ASV scans this is not a matter of style, it is specified. The PCI Security Standards Council's ASV Program Guide requires that scan customers "provide written supporting evidence for disputed findings" and "attest within the ASV scan solution that the evidence is accurate and complete" [1]. Critically, where the evidence is system-generated, the guide expects "screen dumps, configuration files, system versions, file versions, list of installed patches" to be accompanied by documentation of "when, where and how they were obtained," which the guide calls the chain of evidence [1]. The ASV must first determine whether the dispute can be validated remotely, and only where it cannot does it assess whether the written evidence is sufficient [1]. Disputes cannot be removed from a report, customers cannot edit the report, and the security engineer who handled the exception must be named in it [1].
Read that as a specification and the requirement becomes concrete.
The Clone Systems Four-Part False Positive Evidence Pack
Assemble these four artifacts for every disputed finding. A dispute containing all four is normally resolved on first submission. A dispute missing any one of them is where the back-and-forth starts.
1. The vendor security advisory, naming the CVE. Not a release note, not a changelog summary. The distribution's advisory for the specific CVE, which states the package release in which the fix shipped. For Red Hat this is the RHSA; for Ubuntu the USN; for Debian the DSA. This is the document that breaks the link between upstream version number and vulnerability status.
2. Proof of the installed package release on the specific host. Command output showing the exact installed version and release of the package, from the host the finding was raised against, not from a representative system. For RPM systems this is typically the full package NEVRA; the release field, not just the version, is what carries the back-port.
3. Chain of evidence metadata. When the output was captured, on which host, by whom, and how. The ASV Program Guide asks for this explicitly [1]. It is also the difference between an artifact an engineer can accept and a screenshot that could have come from anywhere at any time.
4. A statement connecting one to two to three. One or two sentences: this advisory says the fix shipped in release X, this host runs release X or later as of this date, therefore the reported finding does not apply. Reviewers are not obligated to reconstruct your argument, and when they have to, the dispute takes another cycle.
Note what is not on this list: a rescan. Rescanning an unauthenticated external scan against a back-ported package produces the identical finding, because nothing the scanner can observe has changed.
If your team is spending each quarter re-arguing the same findings, that is a process gap rather than a tooling gap. Clone Systems is a PCI Approved Scanning Vendor, and our vulnerability scanning services include working the dispute and evidence process with your team rather than handing you a report and a deadline. Contact us to talk through your current findings backlog.
Why Do the Same False Positives Come Back Every Quarter?
Because the evidence was treated as correspondence rather than as an asset. Someone assembled the advisory, captured the package output, wrote the explanation, emailed it, got the finding cleared, and then the work product lived in a mailbox. Next quarter the scan runs, the same host advertises the same banner, the same finding appears, and a different engineer starts from nothing.
This is the recurring pattern we see across ASV engagements, and it compounds. Each quarter the backlog of "known false positives" grows, institutional memory about which are genuinely resolved erodes, and eventually a real finding gets waved through on the assumption that it is another back-port artifact. That is the actual risk here, and it is worth being blunt about: a team that has learned to distrust its scanner has lost the control, not just the time.
The 2026 Verizon Data Breach Investigations Report put the median time to patch a vulnerability at 43 days, up from 32 the previous year, and found only 26% of vulnerabilities in CISA's Known Exploited Vulnerabilities catalog were fully remediated in 2025, down from 38% in 2024 [4]. Against remediation curves like that, weeks spent re-litigating findings that were resolved last quarter is not a clerical cost. It is capacity taken directly from the findings that are real.
The fix is unglamorous. Keep a durable false positive register: one row per finding, holding the CVE, the host, the four evidence artifacts, the date the dispute was accepted, and the name of the engineer who accepted it. Review it before each scan cycle rather than after each finding.
Test Your Own Environment: Three Questions
- For the last false positive your team disputed, can you produce the evidence pack today, from a shared location, without emailing anyone? If it lives in an inbox, you will rebuild it next quarter.
- Can you tell, right now, which of your open findings are back-port artifacts and which are genuinely unpatched? If those two categories are mixed in one list, prioritisation is running on guesswork.
- Do your external and internal scan results for the same host ever get compared? A finding that appears externally and not on a credentialed internal scan of the same host is a strong back-port signal. Most teams never put the two reports side by side.
An uncertain answer to any of these is a finding in its own right, independent of what the scan report says.
How Clone Systems Can Help
Clone Systems is a PCI Approved Scanning Vendor and Managed Security Services Provider, which means we sit on both sides of this problem: we run the scans that produce these findings, and we adjudicate the disputes that resolve them. That vantage point is why our position is that the evidence process, not the scanner, is where most programs lose time.
Our vulnerability scanning services pair external and authenticated internal scanning, which is the single most effective structural fix for back-port false positives, because a credentialed scan reads the package database rather than inferring from a banner. For PCI-regulated environments, our ASV scanning covers the Requirement 11.3.2 external scan alongside the dispute and evidence workflow, so a resolved finding stays resolved across quarters instead of resurfacing.
Where a finding is genuinely contested and neither report settles it, our penetration testing services determine whether the reported weakness is actually exploitable in your environment, which is the only evidence that ends the argument for good.
Frequently Asked Questions
Why does my vulnerability scanner report a CVE that is already patched? The most common cause is back-porting, where a Linux distribution applies a security fix to an older package version without changing the upstream version number the scanner reads. The system is patched, but the version string the scanner sees still matches the vulnerable range.
What is a false positive in vulnerability scanning? A false positive is a reported vulnerability that does not actually exist on the target system, most often because detection relied on an inference such as a version banner rather than direct observation. It is distinct from a false negative, an exploitable weakness the scanner failed to report, which Sonatype found to be roughly eight times more common in its 2026 dataset.
How do you prove a vulnerability scan finding is a false positive? Submit the vendor security advisory naming the CVE and the package release that fixed it, command output showing the installed package release on the affected host, chain-of-evidence details covering when and how that output was captured, and a short statement connecting them. The PCI ASV Program Guide requires written supporting evidence and a customer attestation that it is accurate and complete.
Can you fail a PCI ASV scan because of a false positive? Yes. An unresolved finding above the PCI failure threshold results in a failing scan regardless of whether it is technically accurate, which is why the dispute has to be filed and evidenced within the scan cycle rather than after it.
Does authenticated scanning eliminate false positives? Authenticated scanning removes most back-port false positives because the scanner reads the installed package database instead of inferring from a service banner. It does not eliminate severity disputes, which come from disagreement in vulnerability databases rather than from detection.
Conclusion
A scanner that flags a patched system is not necessarily broken. It is reasoning from the only information it was given, and on a back-porting distribution that information is genuinely misleading. The failure is not the finding. It is that most organizations have no repeatable way to produce the evidence that closes it, so the same four findings consume the same week of engineering time every ninety days while the findings that actually matter wait.
Build the evidence pack once, store it somewhere durable, and the problem shrinks to a review step. If your team is heading into a scan cycle with a backlog of findings nobody can conclusively classify, Clone Systems can help you sort the artifacts from the real exposure. Visit clonesystems.com to talk with our scanning team.
References
[1] PCI Security Standards Council — Approved Scanning Vendors (ASV) Program Guide, "Managing False Positives and Other Disputes." https://listings.pcisecuritystandards.org/pdfs/asv_program_guide_v1.0.pdf
[2] Sonatype — 2026 State of the Software Supply Chain Report, Vulnerability Management section, 2026. https://www.sonatype.com/state-of-the-software-supply-chain/2026/vulnerability-management
[3] Red Hat — Security Backporting Practice. Red Hat Customer Portal. https://access.redhat.com/security/updates/backporting
[4] Verizon — 2026 Data Breach Investigations Report. Verizon, May 2026. https://www.verizon.com/business/resources/reports/dbir/
[5] SecurityWeek — August 2026 Patch Tuesday: Microsoft Fixes 421 CVEs, One Exploited Zero-Day, August 11, 2026. https://www.securityweek.com/august-2026-patch-tuesday-microsoft-fixes-421-cves-one-exploited-zero-day/
[6] Clone Systems — In our ASV and vulnerability scanning engagements, the majority of disputed findings are correct disputes submitted with insufficient evidence: the customer has genuinely patched the system, but supplies package manager output rather than the vendor advisory that maps the CVE to the installed package release, and the finding survives the quarter as a result.
[7] Clone Systems — What NIST's 2026 NVD Changes Mean for Vulnerability Management. clonesystems.com/blog/what-nist-2026-nvd-changes-mean-vulnerability-management
[8] Clone Systems — What Your Vulnerability Scan Misses Between Scans (And Why It Still Says "Pass"). clonesystems.com/blog/what-your-vulnerability-scan-misses-between-scans
[9] Clone Systems — Vulnerability Scanning Services. clonesystems.com/vulnerability-scanning