The conversation usually starts the same way. A security team runs their first full credentialed scan — Qualys, Tenable, doesn't matter which — and the findings count comes back at something like 4,200. The instinct is to question the scanner. Too many false positives. Too noisy. Wrong severity thresholds. Maybe we need to tune it differently.
That instinct is wrong. The scanner is doing exactly what it was designed to do: find every known vulnerability on every reachable asset. The problem isn't that the scanner is lying. The problem is that you don't have a system that tells you which findings actually require your attention this week.
What scanners are actually designed to do
Modern vulnerability scanners — Qualys VMDR, Tenable.io, Rapid7 InsightVM — are detection engines. Their job is coverage: find every CVE that matches a software version, every missing patch, every misconfiguration that maps to a known vulnerability ID. They're quite good at this. The CVSS 3.1 scoring system they report against measures exploitability and impact in a vacuum: how hard is it to exploit this if you have access, and how bad is the outcome if you do. It deliberately says nothing about your specific environment.
This is by design, not a flaw. CVSS was never meant to be a remediation queue. The CVSS specification explicitly distinguishes Base Score from Temporal Score and Environmental Score — the latter two are meant to be calculated by the consuming organization. Almost no one does this calculation in practice because it requires data about your specific environment that most teams don't have in a structured form.
So you get a list of 4,200 findings, mostly scored by Base Score, and someone has to decide where to start.
The math behind the noise
Let's put some numbers on this. A typical 1,500-asset environment managed by a 3-person security team might generate between 3,000 and 8,000 findings per scan cycle. If we assume 20% are scored Critical (CVSS 9.0+) and another 35% are High (7.0–8.9), that's 2,200 findings in the "urgent" category alone.
A 3-person team working 40-hour weeks, with security operations consuming roughly half their time, has maybe 60 hours per week to allocate to remediation work — including ticket creation, asset owner coordination, verification, and closure. At even an optimistic 2 hours per finding from identification to closed ticket, that's 30 findings per week. The backlog math is brutal.
And this assumes all 2,200 "Critical" and "High" findings are genuinely urgent. They aren't. A CVSS 9.8 on an internal development box that has no network path to your production environment is categorically different from a CVSS 7.2 on your public-facing API gateway. The scanner gives both findings equal urgency signals.
The three variables CVSS doesn't include
When we built Vendrsec's prioritization model, we started by mapping exactly what information the CVSS Base Score omits. Three variables consistently separated the findings that needed immediate remediation from the ones that could safely wait:
Asset criticality. Which business function does this asset serve? A database containing customer payment data is not equivalent to a build server that only stores compiled artifacts. Criticality isn't a binary flag — it's a weighted score that accounts for data sensitivity, dependency blast radius, and how many business-critical services depend on this asset staying available and uncompromised.
Network reachability. Can an attacker actually reach this asset from outside your network perimeter? Can they reach it from a compromised internal asset through lateral movement? An air-gapped development server might have a CVSS 10.0 vulnerability sitting on it, but if the only path to that server requires physical access to a locked datacenter, your remediation urgency is different from a vulnerability on a load balancer with a public IP.
Exploit availability and active use. Is there a working exploit in the wild for this CVE? Is it listed in the CISA Known Exploited Vulnerabilities (KEV) catalog? Is it being actively used in ransomware campaigns tracked by threat intelligence feeds? A CVE with a public exploit-kit targeting it in active campaigns is fundamentally more dangerous than one where exploitation requires a custom toolchain no threat actor has built yet.
None of these three variables appear in a CVSS Base Score. All three are deterministic of whether a finding actually requires your team's attention today.
Why teams keep blaming the scanner
We're not saying scanners should be configured differently to produce fewer results. The scanner's job is exhaustive detection — turning down the sensitivity reduces your coverage, which is the wrong tradeoff. The problem isn't detection volume; it's the absence of a prioritization layer between detection output and remediation action.
The misdiagnosis happens because the symptom (overwhelming finding counts) looks like a scanner problem. You can suppress certain finding types, raise severity thresholds, exclude certain asset classes — and the list gets shorter. But you've just created blind spots. You didn't reduce your actual risk exposure; you reduced your visibility into it.
We went through this ourselves. Before Vendrsec existed as a product, we were running prioritization in spreadsheets: export findings to CSV, add asset criticality columns manually, cross-reference an internal wiki for exploit intel, and sort by some weighted formula we'd iterate on monthly. It took a senior engineer 6-8 hours per scan cycle to do this correctly. The teams that couldn't afford that time were effectively triaging by CVSS score alone — which means they were remediating by severity theater, not actual risk.
A concrete example: the dev server problem
Consider a plausible scenario from the early months of building this product. An environment with roughly 900 assets — mix of AWS EC2 instances, on-prem servers, and containerized workloads — running full credentialed Tenable scans weekly. The scan returns 3,847 findings. Of those, 612 are CVSS 9.0+.
When we layered network reachability against those 612 criticals, 441 of them were on assets with no inbound path from outside the VPC and no lateral movement exposure from any internet-facing asset in the graph. Genuinely isolated. When we then filtered the remaining 171 by whether CISA KEV or active exploit-kit intelligence matched the CVE, the immediately actionable set dropped to 23 findings.
23 findings, not 612. The other 589 weren't irrelevant — they needed remediation eventually, and they went into a backlog with SLA timelines attached. But they did not require the same drop-everything urgency that 23 findings warranted that week.
That's not scanner tuning. That's prioritization. The scanner found all 612 correctly. The question was always which 23 to start with.
What a prioritization layer actually requires
Building this correctly requires a few things working in concert. You need a structured asset inventory with criticality tags — not just a CMDB export, but an actual weighting model that accounts for business function, data classification, and dependency graph. You need a network reachability model: either a purpose-built tool, or a combination of network topology data and firewall rule analysis that can answer reachability questions programmatically. And you need a live threat intelligence feed that maps CVEs to active exploit activity — the CISA KEV catalog is publicly available and a good baseline, but it tends to lag exploitation by days to weeks.
The output of these three inputs combined against your scanner findings is a prioritized remediation queue with actual signal. Not 4,200 equal-urgency findings. Not 612 criticals. Somewhere between 10 and 40 findings that your team should act on before this week's sprint is over — with the rest tiered into tracked backlogs with SLA deadlines attached by risk tier.
This is the problem Vendrsec was built to solve. The scanner is doing its job. The missing piece is what happens to that output before it reaches your engineering team.