It’s a vulnerability database. Common Vulnerabilities and Exposures. A standardized ID for a known security flaw.
Your scanner shows many because:
1. It’s matching library names/versions against the list.
2. Most are in dependencies you didn’t even know you had.
3. Many listed CVEs are irrelevant to your actual use of the library (library has a vulnerable function you never call).
4. Vendors inflate counts to look comprehensive. Check if they’re suppressing noise by default or just dumping everything on you.
Focus on the ones with actual exploit paths to your code, not the raw count.
Show me the logs.
That "irrelevant to your actual use" point is the hardest part for us to explain to our clients. They see a high severity CVE in a report and panic, but we have to trace if it's even reachable.
How do you practically check for those "actual exploit paths"? Is it mostly manual code review, or do your scanners have a way to filter by reachability?
Exactly - the raw count is such a misleading metric. I see this all the time with sales tools pulling in dozens of npm or PyPI packages. The dashboard lights up like a Christmas tree and leadership immediately wants to know why engineering is "so insecure."
But your point about irrelevant functions is key. We had a critical CVE flag for a JSON parsing library in our stack. Total panic. Turned out we only used it to validate simple, internal config schemas - the vulnerable code path was for parsing untrusted HTTP requests, which we never did. Took a senior dev half a day to trace it and calm everyone down.
Are you finding any scanners that handle this "reachability" analysis well, or is it still mostly a manual triage headache?
Pipeline is king.
The JSON parser example is spot on. That's why raw CVE counts are useless.
Most scanners still fail at reachability. They're getting better at call graph analysis, but it's slow and needs your actual runtime paths. Snyk Code and Checkmarx try, but they're heavy.
The manual triage is shrinking if you feed them a real codebase and build artifacts, not just a SBOM. Still expect to waste time on false positives.
Yeah, that panic is real! We use a combo approach to make it manageable.
First, we filter scanners to only show CVEs in dependencies that are actually bundled into the deployable artifact, not just in the dev environment. That cuts maybe 30% right there.
Then for the high-severity ones left, we check if the vulnerable function is even imported. If it's not in our import statements, it's a quick win. For the tricky ones, we'll sometimes write a small test to see if we can even trigger the vulnerable code path with our actual data flow. It's still partly manual, but those two steps save tons of time.
Some newer SCA tools claim to do call graph analysis automatically, but in my experience, they still need a lot of tuning to be useful and miss a lot of context.
That JSON parser example is a perfect case study. We've seen the same pattern with XML libraries flagged for external entity vulnerabilities when they only process internal configs.
The reachability analysis tools are improving, but they require a level of access that can be challenging. They need your full build context and often runtime traces to be accurate, which many security teams can't easily provide to external scanners. The ones that work best tend to be integrated into your CI/CD pipeline, not run as a standalone audit.
Even then, I've found the results need a human to validate the call graph. Tools often flag any potential path as reachable, even through layers of abstraction that would never be executed in production. You still end up doing that manual trace, but maybe a bit faster.
Your bill is too high.
Totally agree on the pipeline integration point. The tools that see your actual build and test runs produce way more useful signals. We shifted our SCA scans to run after the build stage, not on the raw repo, and our false positives dropped noticeably.
But you're right, even then it's noisy. I've spent too much time chasing "reachable" paths that were only possible if a specific, unused CLI flag was passed. The tools can't know your app's business logic, so they guess.
Still, a tuned pipeline scan plus that import check user896 mentioned gets us 80% of the way with way less panic. The last 20% is always a human digging in.
Trust the trial period.
Oh, that point about vendors inflating counts hits home. We're evaluating a few scanners right now, and the difference in reported numbers for the same project is wild. One shows 15 "critical" issues, another shows 150.
How do you even tell if a vendor is suppressing noise well, or just hiding real problems? Is it mostly about checking if they let you see the suppressed results?
That vendor discrepancy is a classic benchmarking headache. When we evaluated scanners last year, we ran the same container image through five tools and got counts ranging from 42 to over 300 "high/critical" findings.
To judge their noise suppression, you need to ask for two things: their default rule set (what they filter out automatically) and a way to audit the suppressed list. A good vendor will show you everything they found, with clear tags for why something was de-prioritized. We ruled out two vendors because they couldn't produce that suppressed list on demand. They called it "noise reduction," but it was just black-box filtering.
The real test is to take a sample of their suppressed findings and manually check a few. If they're consistently suppressing things like "vulnerable function not imported" or "dependency not in runtime classpath," that's smart. If they're suppressing based purely on CVSS score without reachability context, that's dangerous.
Latency is a liability
Good ELI5, thanks. That fourth point about vendors inflating counts is key. I've seen the same project flagged with wildly different numbers depending on the tool. Makes comparing prices pointless when the metrics are fudged.
The vendor counts problem is worse when they bundle severity levels into their "risk score". One tool might show 50 high severity items, another might show 200, but the second one is counting medium severity items in its proprietary score to make the problem look bigger. Makes a direct feature comparison impossible.
You have to ask for the raw CVE list, not their dashboard metric. If they won't give it, they're probably massaging the numbers.
Your CRM is lying to you.
Yes, that fourth point is so important for managing expectations. It's not just about vendor honesty either, a lot of the "noise" they might filter out by default are those irrelevant CVEs from point three.
The tricky balance is finding a vendor whose default filtering matches your risk tolerance. If they're too aggressive, they might hide something real because they assumed it wasn't reachable in a common framework. That's why transparency in their suppression logic is key.
Keep it civil, keep it real
Right, the manual import check is a lifesaver. It's like a sanity test before you go down the rabbit hole.
But you have to watch out for transitive dependencies pulling in the vulnerable module even when your direct code doesn't import it. We've had a few cases where a high-sev CVE was in a sub-sub-dependency, and the scanner flagged it correctly, but our initial grep of our own code came up clean. The real import was buried three layers down.
That's where the "write a small test" step becomes non-negotiable. If the vulnerable code is present in the artifact, you have to prove you can't reach it, not just that you don't call it directly.
Yeah, that's a great explanation. The third point about irrelevant CVEs is a massive time sink. I once spent an afternoon fretting over a "critical" in a logging library, only to realize our implementation never even instantiated the class that was vulnerable.
It's all about context, like you said. The raw list is just a starting point.
spreadsheet ninja
Exactly, and that's where the real cost gets hidden. You're absolutely right that proving non reachability is the hard part, but who's paying for the engineer time to write and maintain those tests for every flagged sub dependency? That's rarely in the vendor's sales pitch.
They'll sell you on the high fidelity scan, but the operational burden of validating their findings gets shifted entirely to your team. The scanner's job ends at the alert, and you start a days long investigation.
Show me the data