Why 60–80% of automated vulnerability findings are wrong — and what we do about it

If you've ever managed the output of an unauthenticated network scan, an SCA tool, or a SaaS “exposure” product, you know the pattern: 1,000 findings get filed; 950 are nothing; 49 are interesting but already patched; 1 is the one you needed to know about — and it's sitting on page 14, unranked. The industry term for this is the signal-to-noise problem, and it's the reason most security teams stopped trusting scanner output years ago.

Where does the noise come from?

Automated vulnerability scanners produce noise for four structural reasons that no amount of better engineering can fix:

1. Version-only matching.Most scanners flag a vulnerability whenever they detect a software banner whose version is in the CVE's affected range. They have no way to confirm the vulnerable code path is reachable from the internet, or that the configuration that enables the exploitation is in place. The result is a flood of “possibly vulnerable” entries that aren't.
2. Heuristic payload fuzzing. Active scanners send probes and look for response patterns (error strings, time deltas, reflected content). Patterns false-positive on WAFs, edge caches, and idiosyncratic frameworks. The same payload that proves SQL injection on one stack triggers a 500 on another.
3. Aggregation drift. Tools that aggregate findings from threat-intel feeds, public PoC repositories, and OSINT layer in stale data. CVEs disclosed in 2022 may already be patched everywhere — but they still appear in the feed.
4. No reproduction step.Most importantly: scanners don't reproduce the exploit. They flag, then move on. Confirming exploitability is treated as the customer's problem.

What is the actual rate?

Published numbers vary by methodology, but the consensus range is consistent: 60–80% of automated findings are not actionable.Some studies put it higher. The Verizon DBIR regularly notes that “alert fatigue” — analysts ignoring tickets because most are wrong — is a measurable factor in delayed breach detection.

The four-stage pipeline

VulnVerify is built around the assumption that the only way to get the false-positive rate to zero is to put a human in the critical path of every finding. We organise that human time into four stages.

1. Collection

We continuously aggregate vulnerability indicators from multiple underground sources: dark-web forums, exploit marketplaces, leak sites, private threat-actor channels (Telegram/Discord), paste databases, and zero-day broker hints — plus public CVE disclosures and threat-intelligence feeds. Thousands of raw signals per week.

2. Triage

A researcher reviews each raw signal and discards everything that's a false positive, a duplicate, a low-severity finding, or a patched issue. This is the step competitors skip.Without it, customers receive the raw feed and do this work themselves — or, more often, don't do it at all and stop reading.

3. Verification

Every surviving candidate is manually reproduced in a controlled lab. The researcher captures a working proof-of-concept, documents the payload, classifies severity, and writes the remediation report. If the finding can't be reproduced, it doesn't ship. The named researcher signs the report, so the audit trail is attributable.

4. Delivery

The moment a verified finding matches a subscriber's domain, an alert fires on the channels of their choice: email, Slack, custom webhook. Median time from researcher-confirms to customer-inbox is under 60 seconds.

The math, in practice

On a typical week we ingest ~10,000 raw indicators and ship 200–400verified findings to subscribers. That's a 96–97% kill rate. Customers see only the signal — and crucially, they never spend time triaging the noise themselves.

Why this is worth paying for

Researcher time isn't cheap. A working PoC takes between 15 minutes and several hours to develop depending on the vulnerability class. That cost is the line item — and the reason a manually-verified, underground-sourced service has to charge meaningfully more than a raw-data feed.

The justification is the cost of the alternative. One missed critical exposure can cost a mid-market company $4–10M when exploited. A subscription that prevents one of those over the lifetime of the contract is the easiest ROI calculation in security.

Want to see what verified findings on your domain look like? Monitor your domain →