Reachability analysis: why most of your dependency CVEs don't matter

Ayaan Malik — Tue, 28 Jul 2026 10:23:49 +0000

A lockfile is not an attack surface

Traditional dependency scanning works off the manifest: parse the lockfile, look up every package@version against a CVE database (NVD, OSV, GHSA), report matches. It's fast and it's complete — every known vulnerability in every resolved package gets flagged.

The problem is that resolved and used are different things. A typical Node.js project pulls in hundreds of transitive dependencies for a handful of direct ones. Python projects carry dev-only extras. A CVE in a package deep in your dependency tree that nothing in your code ever imports cannot be exploited through your application — there's no code path that reaches it. It's still a real CVE. It's just not your problem this week, and a report that can't tell you which is which trains people to stop reading it.

What reachability analysis actually checks

Reachability analysis answers one narrow, useful question: does any code in this repository import the vulnerable package at all? It's static analysis, not dynamic — no code runs. The mechanics vary by ecosystem but the shape is consistent:

Python — parse import/from statements across the source tree, resolve them against the dependency graph from requirements.txt, pyproject.toml, or poetry/pipenv lockfiles
JavaScript/TypeScript — walk import/require statements (including re-exports) against package.json and the lockfile's resolved tree
Go — cross-reference go.mod requires against actual package imports, since Go's module system already prunes a lot of this at build time
Ruby — match require/require_relative calls against Gemfile.lock
Java/Kotlin — resolve import statements against Maven/Gradle dependency trees, which is the noisiest case given how deep enterprise dependency trees typically run

A package with zero matching imports anywhere in the source tree is unreachable. That doesn't delete the finding — it demotes it. Severity drops a rung, it stops occupying a slot in the top-of-queue list, and it stays fully visible and reversible on demand. The goal is triage, not suppression.

Package-level vs. function-level reachability

It's worth being honest about the limits, because overclaiming here is how security tooling loses trust. What's described above is package-level reachability — it answers "is this package imported at all." It does not answer the stronger question, function-level reachability: does an actual call path reach the specific vulnerable function, with attacker-influenced data flowing into it? That requires a call graph and often taint tracking, and it runs into real limits fast:

Dynamic imports — importlib.import_module(name)-style loading where the module name is computed at runtime is invisible to static import parsing
Reflection and eval — Java reflection, Ruby's send, JavaScript's eval — all can reach code no static graph sees
Plugin/middleware architectures — frameworks that load handlers by convention (file path, decorator registry) rather than explicit import obscure the real call graph
Partial reachability — a package can be imported for one harmless function while the vulnerable function in the same package is never called; package-level analysis can't see that far

The honest framing: package-level reachability is a high-confidence noise filter, not a soundness proof. It will essentially never mark something reachable when it isn't (false negatives on the safe side), but it can occasionally miss a genuinely exploitable path reached only through dynamic loading. That asymmetry is exactly why the output should be a demotion with a visible toggle, not a silent deletion — the deeper call-path analysis that would close this gap is a meaningfully larger project (real call graphs, taint tracking across ecosystem-specific frameworks), and most teams get more value from a fast, conservative filter today than a slow, complete one eventually.

What to do with the "unreachable" pile

Don't delete it, and don't ignore it forever either. A sane workflow:

Let reachable CVEs drive this week's fix queue — that's the actionable set
Batch unreachable CVEs into a periodic dependency-hygiene pass (monthly is usually enough) rather than a per-scan fire drill
If a package shows up unreachable but you know it's loaded dynamically somewhere (plugin registries, dependency-injection containers), flag that pattern once — it's a systemic blind spot worth a manual note, not a per-CVE re-review
Re-check reachability whenever you actually start using a previously-unused package — the demotion is a snapshot of current usage, not a permanent verdict

How Virgil applies this

I've been building Virgil, a security audit tool, and reachability analysis is one stage in its pipeline — after normalizing dependency findings, before ranking. Unreachable CVEs drop a severity rung and collapse out of the default view, with a one-click toggle to see them and a note on why each was demoted. It's combined with finding clustering (grouping duplicate findings by shared root cause) so the queue you actually read is short enough to act on.

Full writeup on the mechanism (with example output) is on the docs page if you want more detail than fits here.

Curious how other teams are handling this — especially the dynamic-loading blind spot. What's worked for you?

DEV Community: Ayaan Malik

Reachability analysis: why most of your dependency CVEs don't matter

What reachability analysis actually checks

Package-level vs. function-level reachability

What to do with the "unreachable" pile

How Virgil applies this