EdgeBreach homeBook a demo

Insights · Security Strategy

Why Most Vulnerability Findings Are Noise, and Why Scanning More Often Won't Fix It

Doug Collins · · 6 min read

A grid of identical, unranked scanner findings beside a four-tier confidence ladder: configuration weakness, known vulnerability, assessed high confidence, and proven

Say your latest scan just finished. It found 847 issues, a few dozen of them marked critical. Your team has seen this movie before. Most of those findings will turn out not to matter, a handful will matter a lot, and nobody can tell which is which without hours of manual work.

This is the most familiar complaint in application security, and it has a direct bearing on a newer problem. Teams now ship weekly or daily, and an annual penetration test can’t keep up with that pace. The obvious response is to scan more often. But if most of what a scanner produces is noise, scanning more often just produces more noise, more often.

How much of it is noise?

You’ll see dramatic numbers quoted for scanner false-positive rates, and some of them come from serious studies. A 2025 analysis by Ghost Security of roughly 3,000 open-source repositories found that “more than 91% of flagged vulnerabilities were false positives”: of 2,116 flagged issues, 180 were real. That’s a vendor study, limited to three bug classes, so treat it as a data point rather than a law.

Peer-reviewed research lands in a similar place by a different route. A 2024 study presented at ISSTA, the main academic conference on software testing, examined static analysis results against 319 real vulnerabilities and found that “at least 76% of the warnings in vulnerable functions are irrelevant” to the actual vulnerability, while 22% of the commits that introduced those vulnerabilities went undetected. A 2022 study of 192 real-world CVEs found that state-of-the-art static C analyzers “miss in-between 47% and 80% of the vulnerabilities.”

Most of this research is about static analysis, where the problem has been studied most closely, but the pattern-matching trade-off described below applies to scanners generally. The honest summary is not one magic percentage. It’s this: scanners produce a lot of findings that don’t matter, and they still miss a lot that does. Precision and recall are both worse than the dashboards suggest.

Why scanners produce so much noise

It isn’t carelessness. It’s a design trade-off.

A scanner decides whether something is vulnerable by matching patterns: a library version against a vulnerability database, a code path against a dangerous-function rule, a response against a known-bad signature. Matching a pattern is not the same as confirming an exploit. The scanner usually can’t see whether a framework sanitizes the input, whether a proxy blocks the route, or whether the vulnerable function is ever called.

Faced with that uncertainty, vendors make a rational choice. A missed vulnerability is embarrassing and a false alarm is merely annoying, so tools err toward reporting. The cost of that choice doesn’t disappear. It moves to your team.

And the volume of things to match against keeps growing. About 48,000 CVEs were published in 2025, a 20% increase over 2024. The first half of 2026 alone produced more than 35,000. Each one is potentially another pattern to flag.

The real cost is attention

The obvious cost of false positives is triage time. Ghost Security’s study estimated manual review at about 10 minutes per finding. At that rate, a single scan with 847 findings is roughly 140 hours of analyst time, before anyone fixes anything. (Illustrative, but the arithmetic is easy to check against your own numbers.)

The bigger cost is what noise does to trust. Google’s engineers wrote about this in a widely cited 2018 article on their own static analysis program: “Google developers have a strong bias to ignore static analysis, and any false positives or poor reporting give them a justification for inaction.” Their internal bar for a check to be shown in code review was fewer than 10% effective false positives. Most security tooling doesn’t come close.

Once developers learn that most findings are noise, they discount all findings, including the real ones.

Severity is not exploitability

Even the findings that are technically accurate often don’t matter much in practice, because a vulnerability existing is not the same as a vulnerability being exploitable in your environment.

The research behind FIRST’s Exploit Prediction Scoring System (EPSS) found that only 6.4% of published vulnerabilities were observed being exploited over the period it studied, and that “prioritization strategies based on vulnerability severity are poor predictors of actual vulnerability exploitation.” CISA’s Known Exploited Vulnerabilities catalog listed 1,484 entries at the end of 2025. That’s a small fraction of the CVEs published in 2025 alone.

That’s the gap a severity-ranked findings list can’t close. “Critical” describes how bad a vulnerability could be in general. It says nothing about whether an attacker can reach and exploit it in your application, today.

Continuous scanning is continuous noise

This is where noise and the velocity gap meet.

If your application changes every week, a once-a-year penetration test leaves almost all of those changes untested. The tempting fix is to run the scanner on every build. It’s cheap, it’s automated, and it feels like coverage.

But a scanner on every build gives you an unranked list on every build. Your team either drowns in triage or, more likely, stops looking. You’ve traded a coverage gap for a noise problem, and the noise problem is arguably worse, because it looks like security.

What actually closes the gap is continuous testing: attempting exploitation against the application as it exists now, and returning results that are graded by evidence rather than by pattern match.

What proof changes

Proof turns a finding from a claim into a fact. “Possible SQL injection in parameter X” invites a debate. “Here is the request that worked, here is what it returned, and here is the fix” ends one. Developers fix proven issues faster because there’s nothing to argue about.

Proof doesn’t mean throwing away everything else. Some issues can’t be safely proven in a live environment, and some are worth knowing about even if they aren’t exploitable today. The useful approach is to grade every finding by the evidence behind it and report all of it, so the proven issues are unmistakable and the rest is honestly labeled.

Questions to ask any testing tool

Does it prove exploitability, or infer it? Ask what share of findings come with an executed exploit and captured evidence.

What does the evidence look like? Request and response, screenshots, reproduction steps. If the answer is a CVSS score and a description, it’s a pattern match.

How does it label what it couldn’t prove? A tool that only shows “confirmed” results isn’t telling you what it couldn’t confirm. A tool that shows everything at the same weight is handing you the triage.

Can it run as often as you ship? If proof only arrives once a year, you’re back to the velocity gap.

How EdgeBreach approaches it

EdgeBreach is continuous penetration testing built on our own reasoning model, trained specifically for software vulnerabilities. Instead of matching patterns, it attempts exploitation against your running application and captures the evidence when it succeeds: the request that worked, a screenshot, and a small redacted sample where exposure has to be shown.

Every finding is graded on a four-step confidence ladder: configuration weakness, known vulnerability, assessed with high confidence, and proven. Every tier is reported, so nothing is hidden, and the proven tier carries the evidence that ends the argument. It runs as often as you ship.

EdgeBreach is continuous penetration testing built on our own reasoning model, trained specifically for software vulnerabilities. To see what it finds in your environment, book a demo.

Sources