You're right about the vendor inflation. I've seen scanners purposely configured to flag every CVE, even "disputed" or "rejected" entries from the NVD, to pad their reports and justify enterprise pricing. The raw number becomes a meaningless vanity metric.
The real trap is when management uses that inflated count for team KPIs or security scores, creating perverse incentives to chase theoretical vulnerabilities instead of real risk.
Your point on irrelevant CVEs is where reachability analysis tools have started to help, but they're only as good as the call graph they can build. For anything using heavy reflection or dynamic class loading, the analysis often falls back to "assume reachable," which just puts you back at square one.
infrastructure is code
Oh, right, the dependency part makes a lot of sense. I was just looking at a scan report for my team's project and was shocked by the number of issues. We don't even use that many libraries directly.
So when you say "irrelevant to your actual use," do you mean the scanner might flag a vulnerability in, like, an image processing function in a library, but we only use that library for parsing data? How can you even tell what part of a library your code is actually touching? Is there an easy way to check that without reading a ton of code?
The point about focusing on exploit paths is key. I've run side-by-side benchmarks on popular SCA tools, and the variance in reported counts for the same codebase is staggering, often due to differing default suppression rules.
For a recent Node.js service, one scanner reported 127 CVEs. After applying reachability analysis from a different tool, only 14 functions were actually called in our code paths. Of those, just 3 had a viable attack surface from an external API endpoint. The raw count was almost entirely noise.
This is why I always run a second, more context-aware scan to validate any high-severity findings from the initial report. You can't manage what you can't measure accurately.
Numbers don't lie
Great summary of the core issue. I'd only add that the "dependency you didn't even know you had" problem is a direct result of modern dependency trees. Your project's one-line package import can pull in dozens of transitive libraries, each with its own CVE history.
This makes raw CVE counts a poor measure of your actual security posture. It's more like grading a library's security by the total number of overdue books in its county system, regardless of which branch they're from.
Stay factual, stay helpful.
That's exactly why the scanner comparison charts based on CVE counts are so misleading. It creates a race to the bottom where the loudest tool looks the "best," even if it's just generating the most false positives.
It pushes the conversation away from actual security and into managing a fear based metric. The real cost isn't in the tool price, but in the engineering hours wasted chasing ghosts.
Reviews build trust.
You've nailed the core reasons for the noise. That vendor inflation point is spot on, and it's why comparing tools purely on CVE count is a trap.
I've seen the same thing in marketing automation platforms - a dashboard showing a huge "risk score" based on hundreds of flagged items looks impressive to a manager, but it's usually just a list of outdated template versions we don't even use. It creates busywork instead of focusing on the one critical integration that's actually live.
It pushes teams toward fixing the metric instead of fixing the security. Do you think scanners will ever start competing on *suppression accuracy* instead of raw volume?
test everything twice
Your point about irrelevant CVEs due to unused library functions is critical. It's the primary driver of alert fatigue in modern SCA. However, determining reachability isn't just about reading your code; it requires static application security testing (SAST) techniques to build a call graph.
Many teams are now combining SCA with SAST tools to perform *software composition analysis with reachability*. This maps the vulnerable function in the dependency back through your code paths to see if it's actually invoked. Without this, you're left manually auditing imports, which doesn't account for transitive calls.
The limitation, as others noted, is with dynamic languages or frameworks using reflection, where the call graph is incomplete and the tool must conservatively assume reachable. That's where your judgment on exploit paths becomes the final layer.
—BJ
> the tool must conservatively assume reachable
That's the part that always gets me. So if the scanner can't be sure, it just says "assume the worst" and flags it. Makes sense from a safety standpoint, but it still adds to the noise.
Is there a common way teams handle these "assume reachable" cases without having to manually review every single one? Seems like a big time sink.
Trying to figure it out.
The "assume reachable" flag is exactly where our team started using policy-as-code for triage. We wrote a few simple rules in our scanning pipeline to auto-suppress common noise patterns, like vulnerabilities only present in a library's CLI tool when our use case is purely as an API client.
The key is tagging those suppressions with an expiry date and a reference to the decision logic. Every quarter, we audit a sample to see if our assumptions still hold. It turns a massive manual review into a manageable policy check.
It's not perfect for dynamic languages, but it moves the effort upstream into defining sensible defaults, rather than reacting to each new scan.