Vulnerability scanning false positives: validate and retest findings

Before you start

A false positive is a scanner reporting a problem that is not there. The opposite mistake costs just as much: a finding that looks implausible can still be real, so the aim is evidence in either direction, not a tidier report. Everything below is read-only on the affected system unless a step says otherwise.

Exploit frameworks are not part of this process. Running exploit code against a live business system to prove a point can cause the outage you were trying to prevent. If genuine proof of exploitability is needed, that is a job for an authorised tester with an agreed window and, ideally, a copy of the system.

• Permission to examine the system. It should be yours, or you should hold the owner's agreement. If the host sits with a hosting or cloud provider, check that provider's security testing policy too, because unauthorised access to a computer can be an offence under the Computer Misuse Act 1990.
• Access to the raw scanner output for the finding (the plugin or check output), not only the summary report.
• Shell or administrator access to the affected host, or a colleague who has it.
• Somewhere to keep the record: a ticket, a shared spreadsheet or your change log.

Start with what the scanner actually saw

Scanners reach a conclusion in one of two ways. Some run an active check: they send something and judge the response. Others infer: they read a version number from a service banner or an installed-package list and look it up against known vulnerable versions. Inference is quick and often right. It is also where most false positives come from, because a version number only tells you what the software calls itself.

A typical case is a scanner that reads a web server package as version 2.4.37 and flags a CVE that the original developers fixed in a later release. The Linux distribution may have copied that fix into its own 2.4.37 build without changing the number. Red Hat's documentation describes exactly this: tools that judge by version number alone produce false positives because they ignore backported fixes.

Open the finding and copy these details into your record before you touch anything else:

• The CVE, plugin or check ID.
• The asset and port.
• The evidence line: the version string, file path or response snippet the scanner quoted.
• Whether the check was remote or credentialed (see the next section).
• The scan date, the scan policy and the scanner's plugin or check feed version.

Check the scanner could see the host properly

A credentialed scan logs in to the system and reads its patch records directly. An unauthenticated scan works from outside and infers more. Tenable describes credentialed scans as able to run a wider range of checks than non-credentialed ones, which generally gives more accurate results. So before blaming the check, ask whether the login worked.

If authentication failed, fix that and rescan before analysing anything else. The finding may well change, and either way you will be arguing from better evidence.

• Nessus: plugin 19506 (Nessus Scan Information) reports whether credentialed checks were possible for the host. Plugin 21745 raises an alert when authentication failed. Look at both for the host in question.
• Rapid7 InsightVM: for authenticated checks, a false positive investigation needs credentials that were applied successfully and a system fingerprint certainty of 1.0. Rapid7 also says investigations are not meant to clear results caused by known scan problems such as weak credentials or an incomplete scan template.
• Other scanners: look for the equivalent line in the scan output that shows the login succeeded and the operating system was identified with confidence.

Compare the installed software with the vendor's fix record

This example uses Linux because backporting makes it the clearest source of version-only false positives. The same logic applies elsewhere: for Windows software or an appliance, compare the installed update or file version with the vendor's own security advisory rather than the product's display name.

Run these commands on the affected host in a normal shell. They only read package information. The Debian and Ubuntu changelog command also makes an outbound network request to fetch the changelog, so the host needs access to its package archive. Replace PACKAGE_NAME with the package the scanner named, YOUR_CVE_ID with the CVE from the finding and SERVICE_NAME with the service that package provides.

1. Identify the exact package and version installed. On Red Hat family systems use the first command. On Debian and Ubuntu use the second, which prints the full package record, so note the Version line.
   bashCopy

   rpm -q PACKAGE_NAME

   bashCopy

   dpkg -s PACKAGE_NAME

2. Open the distribution's own page for the CVE and find your release. Red Hat publishes CVE pages and security advisories. Ubuntu's CVE tracker gives a status per package and per release (such as Fixed, Not affected or Vulnerable) and usually names the package version that contains the patch. Compare that fixed version with what step 1 returned, using the distribution's version numbering and not the upstream project's.
3. Search the installed package's changelog for the CVE. The Red Hat family command reads local data only. A matching line means the vendor shipped the fix in that build. No match is not proof of exposure, because the vendor may have decided the package is not affected or may have fixed it before a CVE was assigned, so fall back on the vendor's CVE page from step 2.
   bashCopy

   rpm -q --changelog PACKAGE_NAME | grep -i YOUR_CVE_ID

   bashCopy

   apt changelog PACKAGE_NAME | grep -i YOUR_CVE_ID

4. If the fix is present, confirm the running service has actually picked it up. Updating a package does not change a process that is already running, so check the service's start time against the update. Success looks like a start time later than the update.
   bashCopy

   systemctl status SERVICE_NAME

5. Write down what you found: package, installed version, fixed version, where you confirmed it and when.

Decide the verdict and write down why

NCSC's vulnerability management guidance (version 2.1, last reviewed 1 May 2026) sorts findings you cannot simply update away into Fix, Acknowledge and Investigate. It also says scanners can produce false positives and that a suspected one should be investigated before it is removed as an issue. Your checks give you one of three verdicts, which map neatly onto that.

Whatever you decide, record the decision, the reasoning and a date. The guidance asks for exactly that: reasons, planned review dates and fix dates, so the rationale still stands up if the issue is exploited later. 'Probably fine' is not a status anyone enjoys reading in an audit.

• Confirmed: the system really is exposed. Treat it as a Fix, with an owner and a date. Prioritise internet-facing services first.
• False positive: the evidence shows the fix is present or the check misread the system. Record the evidence, then decide whether to suppress the finding (next section) so it stops resurfacing.
• Not yet known: you cannot tell either way, for example the vendor has not published a status. Mark it Investigate with a deadline. NCSC is explicit that Investigate should only ever be a temporary status.

Suppress or report a confirmed false positive in Tenable

Skip this section if you do not use Tenable, or if your verdict was not false positive. In Tenable Vulnerability Management an Accept rule hides a finding, which means it also hides it from anyone checking the dashboard later. That is why the scope and expiry matter. Menu names move between releases, so follow the current Tenable documentation if your console looks different.

1. Go to Explore, then Findings, and open the Vulnerabilities tab. Tick the check box next to the finding, select More, then select Recast. The Add Recast Rule window opens.
2. Set Action to Accept and give the rule a Name that includes your ticket or record reference. Add a Description.
3. Set Criteria so the rule matches only the affected asset and finding, not every host with that plugin. A broad rule can hide a real problem on another system.
4. Set an Expires date so the decision comes back for review, and use Additional Comments to point to your evidence record.
5. Only switch on Report as false positive to Tenable if your evidence shows the plugin itself is wrong. It sends your report to Tenable for review, so keep sensitive details out of the comment.
6. Select Save. Tenable has to apply the rule to existing findings, which can take a while if many match, and the Findings view can be cached for up to 60 minutes. Once the finding disappears from the table, note the rule name in your record so you can find it again.

Report a false positive in Rapid7 InsightVM

Skip this section if you do not use InsightVM. An investigation reruns just that vulnerability check against the asset with enhanced logging and, if the same vulnerable result comes back with all prerequisites met, lets you send the evidence to Rapid7. You need the Manage Vulnerability Investigations permission. The rescan covers every instance of that vulnerability on the asset, and it fails if the asset is unreachable at any point, so choose a time when the host will be up and not mid-maintenance.

1. Find the vulnerable result in the Vulnerabilities table on the asset's detail page, or in the Instances or Affects table on the vulnerability's detail page. Investigations cannot be started from node detail pages.
2. Select Investigate in the Investigation column. If you prefer to run it out of hours, tick the option to run the investigation later. Then select Investigate. The status shows Pending and then In Progress while the rescan runs. Carry on when it changes to Review.
3. Select Review to open the Investigation Results window. If the result is eligible, select Send Results. The package that goes to Rapid7 contains an XML report and advanced scan logs, so check that your data handling rules allow sending those. Ineligible results stay in Review until you submit, reinvestigate or close them.
4. Open a case in the Rapid7 Customer Portal and say you have already sent the package from the console. If Rapid7 confirms a flaw in its check logic, its teams will look at a fix.

Retest and keep the evidence

A retest is only meaningful if it compares like with like. Use the same scan policy, the same credentials and the same target as the original scan, or you will not know whether the finding changed or the scan did. Judge the result on a fresh scan, not by editing the old report. A single-host rescan is usually quicker than a full network scan, but how long it takes depends on the scanner and the host, so carry on once the console shows the scan as complete. If a security team or managed provider watches your alerts, tell them a scan is coming so nobody mistakes it for an attack.

1. Run the rescan after the fix, the credentials correction or the scanner change, against the same asset with the same policy.
2. Check that the scan date is later than the change. Then check that the credentialed checks succeeded, as in the earlier section.
3. Compare the result. For a fix, the finding should be gone. For a false positive you have not suppressed, it will still appear, and your evidence record is what explains it. For one you have suppressed, confirm it no longer shows in the active findings list.
4. Complete the record. The template below covers what an auditor, a supplier or a colleague taking over would want to see. Redact passwords, keys, tokens and any customer data from pasted output.
   textCopy

   Finding: YOUR_CVE_OR_PLUGIN_ID
   Asset and port: YOUR_ASSET_NAME and YOUR_PORT
   Scanner, version and feed date: YOUR_SCANNER_DETAILS
   Original scan date and policy: YOUR_SCAN_DETAILS
   Credentialed checks succeeded: yes or no
   Scanner evidence line: YOUR_QUOTED_EVIDENCE
   Host evidence: package, installed version, vendor fixed version, changelog or advisory reference
   Service restarted after update: yes or no, with date
   Verdict: confirmed, false positive or not yet known
   Decided by and date: YOUR_NAME_AND_DATE
   Action: fix owner and deadline, or suppression rule name and expiry
   Retest scan date and result: YOUR_RETEST_DETAILS
   Next review date: YOUR_REVIEW_DATE

5. Set a review date. Close the item only when a fresh scan supports a confirmed fix, or when a false positive verdict is evidenced and any suppression has an expiry.

If it does not go to plan

Most stalls come from one of four situations.

• The credentialed scan will not log in: check the account, its permissions and that the scanner can reach the management port. Until it works, treat remote findings as provisional rather than closing them.
• The changelog search returns nothing: this does not prove the system is vulnerable. Use the vendor's CVE page. If it is silent or says the fix has not shipped, your verdict is Investigate, not false positive.
• The finding persists after the package was updated: check the service was restarted. Then check the scanner is not looking at a second, older copy of the software, such as another instance on a different port or a container image still running the old build.
• A Rapid7 investigation fails: it usually means the asset was unreachable at some point during the rescan. Confirm connectivity and rerun it.