False Positives in Vulnerability Scans: How to Verify Them Without Hiding Real Risk

Every scan has a few findings that make you squint. The web server is flagged for an Apache flaw, but the box runs nginx. A Windows patch shows as missing on a machine you updated yesterday. A client forwards the report and asks, "Is this real?"

Some of those findings really are false positives. Some are not, and calling them false positives is how real risk quietly leaves the report. The goal is not to make the list shorter. It is to make every finding on it true.

Why scanners get it wrong

Most false positives come from a handful of causes:

• Version guessing. Without a login, a scanner reads a service banner and infers the software version. Backported patches (common on Red Hat, Debian and Ubuntu) fix the flaw without changing the version string, so the banner still looks vulnerable.
• Leftover files. An uninstalled program can leave an old DLL or executable behind. A credentialed scan sees the file and reports the old version.
• Pending reboots. The update is installed but not active until the machine restarts. The scanner is right that the old code is still running.
• Shared IPs and load balancers. Two different systems answer on the same address across scans, and findings get attached to the wrong one.
• Generic checks. Some checks test for a behaviour rather than a product, and match systems that behave similarly but are not affected.

Notice that two of those (leftover files, pending reboots) are not really false positives. The scanner found something true; it just wasn't what you expected.

A four-step check

Run each disputed finding through the same steps, so two technicians reach the same answer.

1. Read the evidence, not the title. Scanners include the output that triggered the finding: a version string, a file path, a registry key, a response header. Most disputes are settled here.
2. Confirm on the host. Check the installed package version, the file on disk or the running service directly. For Linux distributions, look up the vendor's security advisory for that CVE, which tells you which package version contains the fix.
3. Check the scan type. If the finding came from a network-only check, a credentialed rescan of that host is often the fastest way to settle it.
4. Decide one of three outcomes: confirmed (keep it), false positive (with proof), or true but different (for example, "patched, reboot pending"). The third outcome deserves its own action, not a dismissal.

Record the proof

A false positive without evidence is just an opinion, and it will come back on the next scan. For each one, keep a short record:

That record does three jobs. It saves the next technician from repeating the check, it lets you suppress the finding in future scans with a reason attached, and it gives you something to show an auditor or a client who asks.

How to show false positives in a client report

Leaving them out entirely makes the report look tidier, but it also makes it impossible to check. A better pattern:

• Keep the main findings and actions limited to confirmed items.
• Add a short appendix listing findings excluded as false positives, each with a one-line reason.
• Mention the count in the summary: "Four findings were reviewed and excluded as false positives; details are in Appendix C."

Clients rarely read the appendix. They notice that it exists, and that is what builds trust.

Watch the trend

If one check produces false positives on every scan, fix the cause rather than re-verifying it each month. That usually means turning on credentialed scanning for that host group, cleaning up the leftover files, or adjusting the scan policy. A false positive you suppress with a documented reason is fine. A whole class of them you dismiss by habit is how a real finding slips through.

Varaxon Scan Hub reads exports from the scanners you already use and turns them into clear, client-ready reports that keep the scanner's evidence next to every finding. Your first 3 reports are free, no credit card needed: varaxontech.com.

Related: Credentialed vs non-credentialed scans · How to read a Nessus scan report