From Scanner Noise to Validated Findings: Killing False Positives in External Recon

A security analyst opens Monday morning to 1,400 new external findings. By the time they finish triaging the first hundred, they have closed seventy as false positives, escalated four that turned out to be duplicates, and quietly stopped reading the severity labels because the labels stopped meaning anything weeks ago. This is not a failure of effort. It is the predictable output of tooling that was built to detect possibility, not to prove reality. And it is expensive: nearly 60% of IT professionals report receiving more than 500 security alerts a day, and a large share of those alerts are wrong.

The cost of that noise is not abstract. Industry reporting consistently places vulnerability scanner false positive rates between 50% and 80%, and in some downstream scanning pipelines researchers have measured rates as high as 97.5% (Finite State industry report). When a third to four-fifths of what lands in your queue is wrong, the queue itself becomes the vulnerability. This article makes the case for the opposite discipline: treating exposure validation as a first-class step, so that what reaches a human is something an attacker could actually exploit today, not something a banner grab thought might be interesting.

Why scanners over-report by design

It helps to be fair to the scanner. A traditional vulnerability scanner is optimized to maximize recall. Its designers would rather flag a hundred things that might be problems than miss the one that is. That bias is rational in a compliance context, where the worst outcome is an undetected CVE. But the same bias is corrosive in external reconnaissance, where the worst outcome is a team that no longer trusts its own findings.

Over-reporting comes from a handful of structural causes that are worth naming, because each one points to a corresponding validation step:

• Version inference instead of behavior. A scanner reads a server banner that says `nginx/1.18.0`, looks up every CVE ever filed against that version, and reports all of them. It never checks whether the vulnerable module is loaded, whether the distro backported a fix, or whether the affected endpoint even exists.
• Signature matching without context. A response body contains a string that matches an admin-panel fingerprint, so the tool reports an exposed admin panel. It does not check whether that panel actually accepts a login or sits behind an authenticating proxy.
• Stateless probing. Most external scanners send one request and judge the answer. They cannot distinguish a database port that is open and unauthenticated from one that is open but firewalled to a bastion, because they never complete the handshake that would reveal the difference.
• Inventory drift. DNS records, cloud resources, and TLS certificates change faster than a weekly scan cadence. A finding that was true on Tuesday's scan is reported on Friday's ticket, long after the resource was decommissioned.
• Severity inflation. CVSS base scores describe worst-case theoretical impact, not the impact in your environment. A 9.8 on an asset that is not reachable from the internet is, in practice, noise wearing a severity badge.

The operational cost: who actually pays for noise

The job a security team is hiring its tooling to do is not "produce findings." It is "close the smallest number of real exposures, fastest." Noise is precisely the thing that prevents that outcome, and it does so through three compounding mechanisms.

Direct triage labor

Every finding that reaches a queue must be read, classified, and either actioned or dismissed. When 60% of professionals see 500+ alerts daily and spend more than 20% of their time prioritizing them, the math is brutal: a single analyst can lose an entire day a week to alerts that should never have been generated. Multiply that across a team and the labor cost of noise rivals the labor cost of remediation itself.

Trust erosion and desensitization

This is the more dangerous, slower cost. When engineering teams repeatedly receive vulnerability reports that turn out to be false alarms, confidence in the security process erodes until people stop paying attention to alerts altogether, ignoring even the real threats hidden among the noise. Security researchers call this vulnerability fatigue, and it is the mechanism by which a high-recall scanner can make an organization less safe than a quieter, more precise one. The damage is reputational inside the org: once the security team is the team that cries wolf, remediation SLAs slip on everything.

The MSSP multiplier

For a managed security service provider, false positives are not an internal inefficiency, they are a margin problem and a churn problem at the same time. An MSSP runs the same scanning stack across dozens or hundreds of tenants. A 70% false positive rate means analysts spend most of their billable attention dismissing noise rather than catching attacks, and every escalation to a client that turns out to be wrong spends trust that is hard to rebuild. The MSSP that can credibly say "if we send it, it is real" wins on both cost-to-serve and renewal rate. That promise is only possible with disciplined validation baked into the pipeline, not bolted on as a manual review afterthought.

Recall finds everything. Precision is what you can act on. The gap between them is paid for, every single day, by the analyst who has to decide what to ignore.— On the economics of security triage

What validation actually means

Validation is the discipline of moving a candidate finding from "this looks like an exposure" to "this is an exposure, and here is the evidence." It is the difference between a false positive and a validated finding. Concretely, a validated finding answers four questions that a raw scanner result leaves open:

1. Is the asset really yours? Confirm ownership through asset discovery lineage, not just because a name resolves. Misattributed assets are a common source of both false positives and dangerous false negatives.
2. Is the exposure reachable from where the attacker stands? Reachability from your scanner's vantage point is not reachability from the internet. Validate from an external, unauthenticated position.
3. Does the vulnerable behavior actually occur? Do not infer from a version or a banner. Elicit the behavior safely: complete the handshake, observe the unauthenticated response, confirm the directory actually lists.
4. Is it true right now? Re-confirm against live infrastructure at report time, because continuous monitoring is the only defense against inventory drift.

Worked example: exposed RDP on port 3389

An exposed RDP port 3389 is one of the highest-signal external exposures there is, which is exactly why it is worth validating carefully rather than reporting on sight. Remote Desktop Protocol is a documented favorite of intruders: Sophos found that cybercriminals abused RDP in 90% of the attacks its incident response team handled in 2023, and external remote services like RDP were the initial access vector in 65% of those cases (Sophos Active Adversary Report). The most severe RDP flaw, BlueKeep, is a wormable unauthenticated remote code execution bug rated CVSS 9.8 (CVE-2019-0708, NVD) and sits in CISA's Known Exploited Vulnerabilities catalog.

The naive scanner finding is simply: "TCP/3389 open." That is a candidate, not a finding. Here is what separates noise from a validated exposure:

The distinction is operational, not academic. A 2019 internet-wide measurement found just under a million non-NLA RDP endpoints and over three million NLA endpoints on the default port (Rapid7 Labs). A scanner that reports all four million as "exposed RDP" has told you nothing actionable. A validation pipeline that surfaces the non-NLA, unpatched, internet-reachable subset has handed you the actual attack surface.

Worked example: dangling DNS and subdomain takeover

A dangling DNS record is the textbook case where unvalidated detection is worse than useless, because the failure modes run in both directions. A scanner that flags every `CNAME` pointing at a third-party provider produces a flood of false positives, since most of those records point at services that are alive and correctly claimed. But the records that genuinely dangle are among the most dangerous exposures on the internet right now.

The threat is not hypothetical. In 2024, Guardio Labs uncovered SubdoMailing, a campaign that hijacked over 8,000 domains and 13,000 subdomains by claiming the abandoned resources that dangling DNS records still pointed to, then used those subdomains to send roughly 5 million authenticated phishing emails a day (Guardio Labs). In early 2025, Infoblox tracked a threat actor it named Hazy Hawk hijacking dangling cloud records tied to organizations including the U.S. CDC and several major consultancies (Infoblox). And a 2024-2025 study of abandoned S3 buckets found roughly 150 deleted buckets still referenced by live DNS, receiving over 8 million requests for things like software updates and VPN configs (watchTowr Labs).

Validating a subdomain takeover candidate means proving the takeover is actually claimable without performing it maliciously:

• Resolve the full chain and confirm the target points at a third-party service that returns a fingerprint indicating an unclaimed or deleted resource, not merely a 404.
• Confirm the provider's claim mechanism is open, meaning the resource name is genuinely available to register, which is what elevates a dangling record from a tidy-up task to an exploitable subdomain takeover risk.
• Verify ownership of the parent zone so you are not reporting an exposure on a domain the client does not actually control.
• Re-check at report time, because cloud resources are reclaimed and reassigned constantly.

Done this way, the output is not "347 CNAMEs to investigate." It is "these three subdomains are claimable today, here is the fingerprint that proves it." That is the contrast effect in practice: the same input data, but one output is a chore and the other is a finding.

Worked example: expired and weak TLS certificates

An expired TLS certificate is the most over-reported and under-contextualized item in most external scans, and it is the cleanest illustration of why validation has to include impact, not just detection. Scanners flag expired and soon-to-expire certificates by the thousand. Most are on staging hosts, internal-only services, or assets already slated for decommission. A few are catastrophic.

The catastrophic ones have a track record. An expired certificate took down O2's mobile network in the UK in 2018, affecting tens of millions of subscribers, with the root cause traced to an expired software certificate in Ericsson's equipment (The Register). Microsoft Teams went dark for hours in 2020 over a lapsed certificate, and Epic Games lost roughly five and a half hours across Fortnite's backend in 2021 to an expired wildcard cert. Certificate-related outages are estimated to cost enterprises millions per incident. The point is not that every expired cert is an O2 event. The point is that severity is a property of the asset, not the certificate, and only validation tells them apart.

Validation for TLS findings therefore folds in weak TLS configuration and reachability context together:

1. Confirm the certificate is actually served on a live, internet-reachable listener, not just present in a certificate transparency log for a host that no longer answers.
2. Establish whether the endpoint is production-facing or a forgotten staging artifact, because that single fact changes the severity by an order of magnitude.
3. Test the negotiated protocol and cipher suite for genuinely weak configurations rather than reporting from a static feature matrix.
4. Re-confirm validity at report time, since a certificate that expires tomorrow is a different finding from one that expired last quarter.

Building validation into the pipeline, not the analyst

The instinct after reading the examples above is to assign a human to validate everything. That does not scale, and it recreates the alert-fatigue problem one layer down. Validation has to be a property of the pipeline, applied between detection and reporting, so that the human only ever sees evidence-backed findings. A few principles make that practical:

• Validate from the attacker's vantage point. Probe unauthenticated, from outside the perimeter, with no special network position. If the exposure only manifests from inside your VPN, it is not an external finding.
• Prefer behavior over inference. Wherever safely possible, elicit the actual behavior rather than reading a version. This is the single largest reducer of false positives.
• Carry the evidence with the finding. A validated finding should ship with the response, fingerprint, or handshake that proves it, so the receiving team can confirm in seconds instead of re-investigating from scratch.
• Make detection continuous, not periodic. Drift is the enemy of validity. Re-confirmation against live infrastructure at report time is what keeps a finding honest, which is the entire premise of continuous attack surface monitoring.
• Apply the same rigor to high-stakes API and data exposures, from missing API rate limiting to missing Supabase row-level security, where the line between a theoretical and an exploitable flaw is whether an unauthenticated request actually returns protected data.

This is the thesis behind how Legba Adversary treats the surface: detection is necessary but not sufficient, and nothing reaches the report until the exposure has been validated against live infrastructure. The goal of external attack surface management is not to find the most things. It is to be right about the things you find, so that the security team or MSSP on the other end can spend their scarce attention on closing real risk.

Scanner noise is a choice, made by tools that were optimized for recall in a world that needed precision. Validated findings are the other choice. The first costs you analyst hours, eroded trust, and the occasional missed breach. The second costs you engineering discipline up front and pays it back every day a real exposure gets closed before an attacker reaches it. Start by looking at one category of your current findings and asking the validation question of each: could you hand this to an attacker as a recipe, and would it still work? The answers will tell you how much of your queue is signal.