Most organisations do not have a vulnerability detection problem. Scanners are inexpensive, coverage is broad, and the output is voluminous. What they have is a prioritisation problem: a backlog growing faster than it is cleared, ranked by a severity score that was never intended to describe risk in a specific environment.
CVSS base scores describe a vulnerability in the abstract. They do not know whether the affected component is reachable from the internet, whether the vulnerable code path is executed at all in your deployment, whether working exploit code exists, or whether a compensating control already blocks the attack. A critical rating on an internal service behind mutual TLS and a medium rating on an unauthenticated internet-facing endpoint can be the wrong way round by any measure that matters operationally.
A more useful ranking combines three signals: exposure — can an attacker reach it; exploitability — does working exploit code exist and is it being used; and blast radius — what does compromise of this component grant access to. Applied to a backlog of fourteen thousand findings, that filter typically reduces the genuinely urgent set to a few dozen, which is a number an engineering team can absorb without the roadmap stopping.
The second half of the problem is capacity. Remediation competes with the product roadmap, and a security function that reports findings without reference to the throughput of the teams expected to fix them will produce a backlog indefinitely. Agreeing a remediation budget per team per quarter, then spending it on the highest-exposure items, is a less satisfying answer than “fix everything” and a considerably more effective one.
None of this is an argument for scanning less. It is an argument for treating the scanner as an input to a risk decision rather than as the decision itself, and for measuring the security function on exposure reduced rather than on findings raised.
