False Positives in Vulnerability Scans: How SaaS Teams and MSPs Can Verify and Record Them

Every team that runs a vulnerability scanner eventually hits the same moment. The report lands, a Critical finding says your web server is running a version of OpenSSH or Apache with a known CVE, and your engineer replies, "That is not true, we patched that months ago." Sometimes the engineer is wrong. Sometimes the scanner is. Knowing which one, quickly and with evidence, is what separates a vulnerability program that builds trust from one that everybody quietly ignores.

This guide is for SaaS founders, lean engineering teams, and MSPs who manage scanning for several clients. It explains why false positives happen, how to verify a suspicious finding without guesswork, and how to record the decision so your next scan, your next audit, and your next customer questionnaire all tell the same story.

What a false positive actually is

A false positive is a finding that reports a problem that does not really exist on the target. The opposite is a false negative: a real weakness the scanner did not report. Greenbone, the company behind OpenVAS, makes a useful point in its report documentation: because a user can identify and manage false positives, but cannot easily see false negatives, its scanner reports all potentially existing vulnerabilities and leaves the final judgment to the person reading the report.

That design choice is reasonable. A scanner that hides anything uncertain would look cleaner and quietly miss real issues. The trade-off is that someone on your team needs a repeatable way to review the uncertain results instead of arguing about them every month.

Why scanners produce false positives

Most false positives come from a handful of predictable causes. Once you recognize the pattern, triage gets much faster.

Version and banner checks on backported packages

Many network checks work by reading a version string from a service banner and comparing it to a list of vulnerable versions. That works well for products that change their version number when they ship a fix. It works poorly on Linux distributions that backport security fixes. Red Hat explains in its backporting overview that it takes a fix from a newer upstream release and applies it to the older package version it ships, so the version number can stay the same while the vulnerable code is gone. A scanner reading only the banner sees an old version and raises the CVE anyway.

OpenVAS tries to be honest about this with its Quality of Detection (QoD) score, a value from 0 to 100 percent that describes how reliable a given detection method is. According to Greenbone's documentation, remote banner checks against products that include the patch level in their version get 80 percent, while banner checks against products that do not (which Greenbone notes is common for open-source software because of backport patches) get only 30 percent. By default, OpenVAS only displays results from checks with a QoD of 70 percent or higher.

Heuristic web application checks

Dynamic application scanners like ZAP send crafted requests and look at how the application responds. A custom error page, a WAF that returns a generic block message, or a single-page app that answers every path with the same HTML can all look like evidence of a weakness. ZAP itself models this uncertainty: when you add or edit an alert in its Add Alert dialog, the confidence field ranges from False Positive and Low through Medium, High, and Confirmed.

Weak template matchers

Template-based scanners such as Nuclei decide whether a target is vulnerable using matchers on the response. The Nuclei matchers reference notes that when a template uses several matchers, the default is an OR between them, and template authors can set matchers-condition: and so a result only fires when every matcher is true. A template that relies on a single loose word match is more likely to trigger on an unrelated page that happens to contain the same text.

Network devices in the path

Load balancers, reverse proxies, and firewalls sometimes answer on behalf of the server behind them. Greenbone's QoD table gives some remote probe checks only 50 percent for exactly this reason: an intermediate system may appear to confirm a detection when it is not clear the real application answered at all.

How to verify a suspicious finding

The goal of verification is not to prove the scanner wrong. It is to collect enough evidence that anyone reviewing the decision later, whether that is a teammate, an auditor, or a client, would reach the same conclusion. A practical approach works through four questions.

1. What evidence did the scanner use?

Open the finding and read the detection detail before touching the server. A finding based on a banner string deserves more skepticism than one based on a response that could only come from vulnerable code. In OpenVAS results, the QoD value and detection method tell you this directly. In ZAP results, look at the evidence and attack fields to see what request triggered the alert.

2. What is actually installed?

For package-level findings, check the installed package and its changelog on the host rather than the advertised version. On Red Hat-family systems, the package changelog usually lists the CVEs a build fixes. On Debian and Ubuntu, the distribution security trackers show which package versions contain the fix for a given CVE, such as the Ubuntu CVE tracker. If the installed build includes the fix, you have strong evidence of a false positive caused by backporting.

3. Can you reproduce the behavior?

For web findings, replay the request the scanner sent and compare the response to a normal one. If an "SQL injection" alert disappears once you see that every malformed request returns the same WAF block page, you have learned something useful about both the finding and your WAF. Keep the request and response as evidence.

4. Does a compensating control change the risk, rather than the facts?

This is where many teams blur two very different decisions. If the vulnerable code really is present but unreachable because of a firewall rule or a disabled feature, the finding is not a false positive. It is a real vulnerability whose risk you have decided to accept or mitigate. Recording it as a false positive hides a real weakness that could become exposed the next time someone changes a firewall rule.

False positive or accepted risk: get the label right

The difference matters to auditors, to customers reviewing your security posture, and to your own engineers six months from now.

Situation	Correct label	Why
Banner shows an old version, but the installed package includes the backported fix	False Positive	The vulnerable code is not present
WAF block page triggered a heuristic web alert and replaying the request shows no injection	False Positive	The behavior the alert describes does not exist
Vulnerable service is present but only reachable from an internal admin network	Accepted Risk (or remediate)	The weakness is real, its exposure is limited
Legacy component cannot be upgraded until a planned migration	Accepted Risk with a review date	The weakness is real and you have chosen to tolerate it for now

Greenbone handles this in OpenVAS with overrides, which let a user change how a known result is treated in future reports. Whatever tool you use, the principle is the same: the decision should live in the scanning platform next to the finding, with a note explaining the evidence, not in someone's memory or a chat thread.

Recording decisions in Panoptic Scans

Panoptic Scans combines OpenVAS network scanning, ZAP web application scanning, Nmap port scanning, and Nuclei template checks, so findings from different detection styles land in one Vulnerabilities dashboard. According to the vulnerability management documentation, findings start as Active, and you can move a finding to Accepted Risk or False Positive. You can also undo either decision to return the finding to Active when you want to review it again.

A few details make that workflow practical for small teams:

• You can filter the dashboard by severity, status, and scanner type, which makes it easy to review only the findings that are still Active after a triage session.
• Vulnerabilities auto-resolve when they are no longer detected in later scans, and they can reactivate if the same issue appears again, so the dashboard stays aligned with the current state of your targets.
• You can export vulnerabilities to CSV for ticketing systems or audit evidence.
• Teams that automate triage can change vulnerability status through the Developer API and MCP server, where the status values are Unresolved, Resolved, Accepted, and False Positive.

Panoptic Scans does not decide for you whether a finding is a false positive. That judgment still needs a person who understands the system. What the platform gives you is one place to record the decision, filter it, and revisit it.

A triage rhythm that works for MSPs and small SaaS teams

For an MSP managing dozens of client environments, false positives are not just an annoyance. They are billable time and a credibility risk. If you send a client a report full of findings their admin can disprove in five minutes, the real findings in the same report lose weight. A few habits help.

Triage right after the first full scan of a new target. The first scan of any environment produces the most noise. Review it carefully once, record every false positive and accepted risk with notes, and later reports become much shorter and more credible. Our vulnerability scanning for MSPs page covers how Panoptic Scans handles multi-client scanning.

Write the evidence into the decision. "Not vulnerable" is not evidence. "Installed package build includes the fix for this CVE per the vendor changelog" is. That one sentence will save you a long conversation during a SOC 2 audit or a customer security review.

Put a review date on accepted risks. An accepted risk without an expiry slowly turns into a forgotten vulnerability. Revisit them on a schedule, for example quarterly, or whenever the underlying system changes.

Re-check false positives after big changes. An operating system upgrade, a new WAF policy, or a switch to a different base container image can change what the scanner sees. Panoptic's undo action returns a finding to Active so you can re-verify it.

Do not tune away whole categories. If one check produces repeated false positives on a specific host, record decisions for that host. Avoid hiding a whole class of findings across every target just because it was noisy once.

Why this matters for SOC 2 and customer trust

Auditors and enterprise customers rarely expect a scan report with zero findings. What they look for is evidence that you scan regularly, review what the scanner reports, and make documented decisions about each result. A clean history of findings that were fixed, accepted with a reason, or marked as false positives with evidence is far more convincing than a spreadsheet of hundreds of untouched alerts. If you share scan evidence through Vanta, the Panoptic Scans Vanta integration can sync results automatically so that history stays current.

For a broader view of what to fix first once the noise is gone, see our post on vulnerability prioritization for SaaS.

Conclusion

False positives are a normal side effect of scanners that would rather show you something uncertain than hide a real weakness. They become a problem only when nobody has a consistent way to verify them and record the result. Check what evidence the scanner used, confirm what is really installed or reproducible, keep false positives separate from accepted risks, and write the evidence down where the finding lives. Do that, and every future report gets shorter, more credible, and easier to act on.

If you want to see how your own environment looks through OpenVAS, ZAP, Nmap, and Nuclei together, you can start a free trial or compare Panoptic Scans plans.