The Security Org’s Biggest Frustration
I've been talking with all sorts of engineering teams this week - startups, big companies, you name it. When I brought up how they're handling vulnerabilities, I kept hearing the exact same thing from everyone: "We're drowning in vulnerabilities."
It's pretty eye-opening that this is still happening everywhere, regardless of company size or resources. These teams are completely overwhelmed by the flood of security issues they're facing.
Security teams spend countless hours triaging alerts, reviewing scanner results, and chasing down fixes. Yet the end result is often the same - massive lists of vulnerabilities, no clear prioritization, and a creeping sense of helplessness.
The frustration is real:
- Too many vulnerabilities, not enough clarity on what actually matters.
- False positives abound.
- Developers push back, asking “Why should we fix this?”
- Time and resources are limited.
The feeling is familiar: “We could patch it all, but we’d never ship anything again.” So, vulnerabilities pile up. Some are benign. Some are business-critical. But without a clear way to tell the difference, they’re all too easy to ignore.
Where Prioritization Falls Short
Security teams have turned to frameworks and scoring systems to make sense of the chaos. But most efforts, while well-intentioned, still leave gaps.
CVSS: Severity Without Context
The Common Vulnerability Scoring System (CVSS) is the industry default for severity scoring. It rates vulnerabilities on a scale of 0 to 10 - but what it doesn't do is tell you whether that vulnerability is likely to be exploited in the real world.
CVSS often inflates scores for theoretical issues that sound scary but are rarely (if ever) exploited. For example, a low-complexity remote vulnerability might get a score of 9.8 - even if there’s no known exploit, no real-world impact, and no attack ever recorded. Teams patch high-CVSS issues only to discover later that they were chasing ghosts.
CISA KEV: Useful but Too Narrow
The CISA Known Exploited Vulnerabilities (KEV) list helps answer the question “Has this actually been exploited?” It’s a valuable filter - but a limited one. It only includes vulnerabilities with confirmed real-world exploitation, and that confirmation often comes years late.
Take for example the jQuery CVE-2020-11023 XSS vulnerability. Disclosed in 2020. Added to the KEV list in 2025. That’s five years where teams could've dismissed it as "theoretical" - until attackers proved otherwise. (Hacker News report).
EPSS: Predictive… In Theory
The Exploit Prediction Scoring System (EPSS) was designed to predict the likelihood a vulnerability will be exploited in the next 30 days. In theory, it's the predictive counterpart to KEV.
In practice? It often lags behind the curve.
When the same jQuery CVE-2020-11023 was added to KEV, its EPSS score spiked after the listing - not before. That pattern has shown up in multiple cases, making it hard for teams to use EPSS as an early warning system.
EPSS remains promising - but not yet predictive enough to prevent the next breach.
LEV: Likely to be Exploited, but lagging behind EPSS
Recently introduced, NVD LEV approximates whether a vulnerability is likely being exploited by using sustained high EPSS scores. Unlike EPSS, it's not predictive - its purpose is to enhance the Known Exploited Vulnerabilities (KEV) list by surfacing likely ongoing, but undocumented, exploitation.
“Show me it’s exploitable.”
The tension is real.
That’s the developer’s challenge to every ticket. They don’t want to waste time patching what they see as “hypothetical” threats. And frankly, they have a point. Developers are under constant pressure to ship features, not patch theoretical bugs.
Security teams, meanwhile, struggle to prove urgency. When the only justification is “CVSS 9.8,” they face pushback - especially when the vulnerability affects dead code paths, unused packages, or tools not even active in production.
This leads to the worst-case scenario: critical vulnerabilities getting ignored because the signal is buried under noise.
Reachability: Fighting False Positives
One of the best ways to reduce noise is reachability analysis - assessing whether a vulnerable piece of code is actually used by the application.
Static Reachability
This method scans the codebase without executing it. It maps out all potential code paths and flags if the vulnerable function could be called.
- Pros: Fast, covers entire codebase
- Cons: Flags dead code or unused functions - higher false positives. It is also limited by the capacity of the scanner to understand frameworks and language edge cases.
Runtime Reachability
This observes application behavior during runtime (tests or live traffic). It checks whether the vulnerable code was actually executed.
- Pros: Strong signal - if it ran, it’s reachable
- Cons: Limited by test coverage and user traffic patterns. Adds overhead to production workloads. Sometimes not possible to implement (serverless, frontend).
- Pitfall: If a malicious payload activates a hidden path that tests never trigger in nature, runtime analysis will miss it.
Case in Point
One enterprise ran several reachability tools across their app stack. Each tool gave different results - why?
Because reachability is not absolute. It depends on:
- What tests were run
- What inputs were given (in nature)
- What code paths the scanner could map
- The reachability analysis capacity, depth and breadth
The insight? Reachability isn’t a binary yes/no - it’s either “observed” or “unknown.”
False negatives are a real risk. That’s why reachability should guide prioritization, not gatekeep it. Don’t ignore a vulnerability just because a tool didn’t see it run.
The Auditor’s Perspective
Even if your developers are convinced that vulnerable code is unreachable, your auditors won’t care.
“If it’s bundled, it’s in scope.”
That’s the reality of modern compliance audits. Whether or not the code runs, if it’s included in your production build or shipping artifact, it’s considered a liability.
Reachability may buy you time - it won’t buy you a pass.
A Frustration We Must Fix
The flood of vulnerabilities isn’t just inconvenient - it’s dangerous.
When teams are overwhelmed, they default to ignoring. But real-world breaches rarely come from obscure zero-days - they come from known, ignored vulnerabilities that no one got around to fixing.
Vulnerability overload isn’t a visibility problem - it’s a remediation problem. And manual triage can’t keep up. The only sustainable path is automation that solves the issue from its root.
Let automation do the heavy lifting - and free your team to move fast and stay secure!
