Introduction
Every software team ships code it did not write. Most of a modern application is open-source dependencies, and each one carries its own history of CVEs. Traditional software composition analysis (SCA) tools like Dependabot, Snyk, and osv-scanner compare the versions in your lockfile against public vulnerability ranges and alert on every match. That match is a starting point. It does not tell you whether the vulnerable code runs in your application at all: a package can sit in your dependency graph, get imported, and still be harmless if the vulnerable function is never called or no attacker-controlled input reaches it.
The distance between "a vulnerable version is present" and "an attacker can exploit it here" is where security teams lose weeks. ZeroPath closes that distance with reachability and exploitability triage: for each flagged CVE, an AI agent investigates your actual code and returns a verdict (likely exploitable, needs review, likely not exploitable, or not yet analyzed) with the file and line to back it up.
Why do dependency scanners flag so many CVEs that don't matter?
Version-range matching is blind to how you use a package. An advisory says "versions 2.0 through 2.7 of library X are vulnerable." If your lockfile pins 2.4, every scanner flags it, whether your code calls the vulnerable function or imports the library for one unrelated helper. In practice, most of those alerts are never reachable in the app that receives them, which is why an unfiltered SCA queue routinely runs into the hundreds or thousands per repository. For an AppSec lead, that is a backlog no team can clear. For a CISO, it is budget spent chasing issues that were never exploitable in the first place.
Reachability vs. exploitability: what's the difference?
Reachability asks whether your code actually invokes the vulnerable path. Exploitability asks whether an attacker can trigger it, given real inputs, configuration, and trust boundaries. Reachability is a necessary condition for exploitability, not proof of it. A vulnerable function called from a request handler that receives user input is both reachable and likely exploitable. The same function, called only from a build-time script with operator-supplied input, is reachable but far less exploitable. Keeping the two ideas apart lets you rank a short list of genuine risk instead of a long list of theoretical ones.
How does ZeroPath decide whether a dependency CVE is exploitable?
ZeroPath treats the version match as the input, then investigates. An AI agent reads through the repository the way a security engineer would: reading the advisory, finding where the package is imported, tracing whether the specific vulnerable function is actually called, and checking whether attacker-controlled data can reach it. When it confirms an exploitable path, it records the finding at the exact vulnerable line rather than the manifest, and files one finding per distinct exploitable path.
Two design choices matter here. First, the agent does not lean on a precomputed static call graph. Most function-level reachability tools build one, which is why they typically support only a handful of languages. ZeroPath's agent reads source directly, so triage spans all 13 packaging ecosystems it supports: npm, PyPI, Maven, Go, NuGet, RubyGems, Cargo, and more. Second, it reads your threat model. If you have marked a subtree out of scope or written down how a service is deployed, those facts steer the verdict, so noise in areas you have already reasoned about stays quiet.
Reachable, or actively exploited? KEV and EPSS
Reachability tells you whether a vulnerability is exploitable in your code. Two industry feeds tell you whether it is being exploited in the wild, and ZeroPath enriches every CVE finding with both, refreshed daily. CISA's Known Exploited Vulnerabilities (KEV) catalog flags CVEs under active exploitation, with the date CISA added it and a known-ransomware indicator. FIRST's Exploit Prediction Scoring System (EPSS) estimates the probability a CVE will be exploited in the next 30 days, with a percentile rank. A finding that is reachable, KEV-listed, and high-EPSS is your top priority. A not-reachable finding with a low EPSS score and no KEV listing can usually wait.
Why does "not tested" never mean "safe"?
Honesty is the whole point of triage. ZeroPath separates "we analyzed this and found no reachable path" from "we have not analyzed this yet," and never shows the second as the first. A package stays "not tested" until analysis runs, and if an assessment cannot finish, the finding shows up as needs-review instead of disappearing from the report. When exploitation depends on something the scanner cannot confirm from code alone (for example, "only called with server-controlled input" or "requires a specific runtime configuration"), ZeroPath attaches those preconditions to the finding so a human can judge the rest. Reachability is an AI-assisted, probabilistic signal, and it can miss reflection, dynamic dispatch, and deserialization. Treat "not reachable" as a reason to deprioritize, not a license to ignore a critical or KEV-listed advisory.
From triage to fix
Triage is only useful if it shortens the path to a fix. Reachable findings flow straight into auto-remediation: ZeroPath opens an upgrade pull request that selects a version resolving the CVE without dragging in new ones, paired with blast-radius analysis that shows which call sites the upgrade touches. The exploitable queue becomes a set of reviewable pull requests instead of a spreadsheet.
Key takeaways
- Version-range matching tells you a vulnerable package is present, not that it is exploitable in your app.
- Reachability (is the vulnerable code invoked?) and exploitability (can an attacker trigger it?) are distinct, and you need both to rank real risk.
- ZeroPath uses an AI agent that reads your code instead of a static call graph, so triage covers 13 ecosystems and cites the exact file and line.
- KEV and EPSS, refreshed daily, add real-world exploitation signal on top of reachability.
- ZeroPath never shows "not tested" as "safe." Un-analyzed findings, preconditions, and probabilistic caveats stay visible instead of hidden.
See it on your own dependencies
Point ZeroPath at a repository and watch which dependency CVEs survive triage, and which were never exploitable to begin with. Get a demo of ZeroPath.
