Introducing Reachble — open-source VEX generation for npm projects, backed by
import-graph reachability analysis.

I got tired of triaging the same CVE three times. The scanner flags it, someone
goes and looks at the dependency tree, someone else goes and looks at whether
we actually call that function, and then someone writes it down in a spreadsheet.
A month later: same CVE, fresh install, do it again.

That's what I built Reachble to fix.

The noise problem

Run npm audit or drop your package-lock.json into Snyk. You get a list.
Maybe 30 CVEs. Maybe 200. HIGH, CRITICAL, fix immediately, it says.

Most of them cannot be exploited in your code.

Research consistently shows 60–80% of CVEs flagged by dependency scanners live
in code paths that are never called. The vulnerable function exists somewhere
in your node_modules — but your application never imports it, never invokes
it, never reaches it. It's like being told your house has a gas leak because the
neighbor two streets over has one.

The scanner isn't lying. It's doing its job: flagging what's in the dependency
tree. The problem is that "in the tree" ≠ "reachable" — and nobody was
forced to care until now.

SBOM mandates made this urgent

US Executive Order 14028 and the EU Cyber Resilience Act both require Software
Bills of Materials (SBOMs). An SBOM without a VEX document is incomplete.

VEX (Vulnerability Exploitability eXchange) is the machine-readable
companion to your SBOM. It answers: "Yes, CVE-2021-23369 is in our dependency
tree — but the vulnerable function is never called. Here's the evidence."

Right now, VEX is produced manually. Security engineers triaging CVEs, writing
justifications in spreadsheets, marking things not_affected based on memory
and gut feeling. It doesn't scale, it isn't auditable, and it's going to get
worse as SBOM requirements tighten.

What Reachble does

Reachble answers the question your scanner can't:

Can an attacker actually reach this vulnerable code from user-controlled
input in my application?

npx reachble scan

It parses your lockfile, pulls CVE data from OSV.dev, NVD, and GHSA (with EPSS
scores), extracts which specific functions the CVE is about — from OSV's
affected_functions, fix-commit diffs, and NVD descriptions — then walks your
import graph to see if any code path reaches them.

Output is CycloneDX VEX + OpenVEX — machine-readable, CI-gatable,
audit-ready. You get a document you can ship alongside your SBOM instead of a
spreadsheet.

Verdict tiers

Rather than amplifying the scanner's severity number, Reachble gives you an
exploitability verdict grounded in your actual code:

CRITICAL — reachable from unauthenticated external input (HTTP, CLI, file, env)
HIGH     — reachable from authenticated route or internal service
LOW      — reachable in code, no external input path found
SAFE     — vulnerable symbol never reached → VEX `not_affected`

SAFE maps directly to VEX not_affected with justification
vulnerable_code_not_in_execute_path. No hand-writing, no judgment call.
The evidence is in the output.

A concrete example

Take lodash 4.17.18 and a minimal Express app. Two CVEs, side by side.

The app imports template from lodash in a route handler:

// src/routes/render.ts
import { template } from 'lodash'          // ← CVE-2021-23337

const compiled = template('Hello, <%= user %>!')

It does not import trim, trimStart, or trimEnd (CVE-2020-28500).

$ reachble scan --path . --format table

Package   Version   CVE              Verdict   CVSS   Reason
──────────────────────────────────────────────────────────────────────────
lodash    4.17.18   CVE-2020-28500   SAFE      5.0    Vulnerable symbol(s) not imported from lodash
lodash    4.17.18   CVE-2021-23337   LOW       7.5    Vulnerable symbol(s) imported from lodash

2 packages · 2 CVEs · 0 CRITICAL · 0 HIGH · 1 LOW · 1 SAFE
VEX written to reachble-vex.cdx.json

The VEX output for the SAFE verdict:

{
  "id": "CVE-2020-28500",
  "analysis": {
    "state": "not_affected",
    "justification": "code_not_reachable",
    "detail": "Vulnerable symbol(s) not imported from lodash — trim/trimStart/trimEnd do not appear in any import statement"
  }
}

Your scanner flagged both as HIGH. Reachble tells you which one to actually fix —
with a machine-checkable justification for the one you're closing.

How the import graph works

Reachble uses @typescript-eslint/parser to build a static import graph
across your project. No tsconfig.json required — it works on plain JS, TS,
and mixed projects. It maps:

1. Every import in every file in your project
2. Whether the imported module is from a vulnerable package
3. Whether the imported symbol matches the CVE's affected function/class

This is import-level analysis for the current MVP — fast and
zero-configuration. V1 will use ts-morph for full function-level call graphs
and entry-point detection (Express/Fastify/Next.js routes, with
authentication awareness), which is how LOW upgrades to CRITICAL when a
real unauthenticated attack path exists.

Does it work on real projects?

I ran it on three real-world Express apps before publishing:

No false SAFEs — every package marked SAFE was genuinely absent from the import
graph. Most LOWs came from packages with no affected_functions in OSV, so
Reachble conservatively flags them at package level. The V1 fix-commit extraction
work is what converts those from package-level to symbol-level.

How it compares

¹ Based on public Endor Labs documentation as of 2026. If anything's inaccurate, open an issue.

Status

The MVP is working: lockfile parsing (npm/yarn/pnpm), CVE resolution from
OSV + NVD + GHSA + EPSS, import-graph reachability, and CycloneDX VEX +
OpenVEX output. 357 tests, lint clean.

V1 adds:

• ts-morph full call-graph (function → function, not just import → module)
• Entry-point detection: Express/Fastify/Next.js routes, CLI args, env reads
• Authentication awareness (CRITICAL vs HIGH distinction)
• Fix-commit diff symbol extraction (higher confidence on affectedSymbols)

Get it

npx reachble scan
# or
npm install -g reachble
reachble scan --format vex --fail-on high

GitHub: https://github.com/RJonMshka/reachble (MIT, no telemetry)

If you're working in a JS/TS codebase and have SBOM requirements coming at you,
give it a run and tell me what breaks. Issues and PRs welcome.