The Counterintuitive Choice Breaking Today’s Security Programs
Every CISO faces a moment of truth during application security tool evaluation and selection — a decision that will determine the success to vulnerability management at scale.
Two vendors present their solutions:
Tool A finds 500,000 vulnerabilities in your test application…
Tool B discovers 501,000.
The choice seems obvious - more comprehensive coverage must mean better vulnerability management, right?
Over the past 20 years, I’ve seen this seemingly straightforward question spiral the security industry down into the current, desperate situation. Decades of investment in detection capabilities, and rewarding vendors for noise, has led to an ecosystem where organizations are drowning in vulnerability backlogs.
Why Aren’t More Security Vulnerabilities “Better”?
It’s natural to think that “more coverage” (the positive spin on “high noise”) should lead to more risk elimination. Unfortunately, the sheer volume of findings often renders traditional security backlog management approaches ineffective. The fishing expedition mentality driven by fear and compliance make the wrong choice feel intuitively correct.
Fear of Missing the Critical Flaw I mean, we’re here to stop breaches, right? This fear creates powerful psychological pressure to choose tools that find everything, even when “everything” includes massive amounts of noise, leading to security alert fatigue and mistrust.
Even just one critical vulnerability in some crevice of the organization can cost billions. This fear creates powerful psychological pressure to choose tools that find everything, even when "everything" includes massive amounts of noise.
Vendor Incentive Alignment Security vendors have built entire business models around finding more issues. Companies drive the market to compete on detection capabilities, and not customer remediation rates. What happens downstream is really a “people and process problem” that sits comfortably out of their purview.
Audit and Compliance Pressures Regulatory frameworks and security audits often measure programs by their ability to identify vulnerabilities, with less focus on than their ability to eliminate them. Our tool choices end up reflecting this.
The Downstream Impact on AppSec of Scanner Noise
Choosing high-noise security tools triggers a cascade of organizational dysfunction that undermines the security posture these tools were meant to improve.
Developer Rebellion and Tool Exile When security tools generate overwhelming amounts of false positives, developers inevitably push back. They have business value to create, deadlines to meet, and limited patience for investigating issues that turn out to be irrelevant. Developers tend to be more politically powerful because they create value and outnumber security teams significantly. Their time is just way more precious. It’s just math.
This power imbalance leads to tools being relegated to the deep dark security dungeon — isolated from development workflows where they accumulate findings but cannot drive remediation. The tools continue running, generating reports that document problems without solving them.
The Bulk Suppression Reality Security professionals facing impossible triage loads resort to survival tactics that compromise security effectiveness. Even experienced analysts end up "select all, right-click, suppress" for hundreds or thousands of similar-looking findings because individual triage at scale becomes mathematically impossible.
No doubt, this systematic suppression often eliminates legitimate threats along with noise. When security professionals must process findings faster than they can properly analyze them, pattern-based suppression becomes the only viable approach - but it introduces blind spots that attackers will exploit.
Attention Fatigue and the Lost Signal The human brain cannot maintain focus when reviewing thousands of repetitive alerts. We even have a name for this psychological phenomena. Security analysts suffering from attention fatigue will inevitably miss the critical finding hidden among false positives. As one practitioner observed, "You're just never gonna get it right when you see the one" after examining similar alerts thousands of times.
A few years ago, I would tell you: measure the tools on how actionable their results are, and how good they are at finding only the subset of vulnerabilities that matter to you.
Today, my answer is different.
Why “More Vulnerabilities” Could Be Better — But Only Because of AI
Here’s the twist: finding more can be better — if and only if you can convert that detection firehose into rapid, developer‑accepted fixes. That requires an AI‑first approach to triage, evidence gathering, and remediation delivery.
The old trade‑off between coverage and remediation capacity collapses when:
Triage scales at the speed of inference. Large volumes aren’t a problem if machine judgment can sort out the signal from the noise, adjudicate risk, rank by exploitability, and generate proofs/evidence automatically.
Context is fused, not fetched. AI agents can ingest code, configs, IaC, and the results to determine if a finding is a problem here, in this repo, this environment.
Fixes ship where developers work. Remediation arrives as ready‑to‑review PRs/merge requests with tests and rollback guidance — not as tickets.
Feedback is learned, not lost. Every human decision (merge, reject, comment) becomes labeled data, continuously improving ranking and fix suggestions.
Without these capabilities, “more findings” just accelerates failure. With them, the marginal finding has near‑zero cost and sometimes uncovers the next incident‑preventing fix.
The Counterintuitive Choice (Revisited)
When you can triage, verify, and remediate at the speed of inference, “more findings” stop being a liability. The correct decision flips from pick the tool that finds fewer things to pick (or instrument) the ecosystem that can fix more things, faster.
In other words: choose the stack that turns noise into merged PRs. That’s the only coverage that matters.
