Fix the vulnerabilities your code actually reaches
A vulnerable function you never call isn't an exposure — it's noise. SBOMVault goes past import-level reachability to the symbol level: which functions of each npm package your code actually references. Findings in code paths you never execute drop down the queue, so your team works what matters.
From “is it imported” to “is it called”
Reachability is pure static analysis — no code execution. It runs inline on a repo-scanned SBOM, fetching your first-party source and walking it for the symbols each dependency actually exposes to your code.
01
Import-level baseline
First we establish which packages your first-party code actually imports — not just what the lockfile resolves.
02
Symbol-level precision
Then we parse your source with a TypeScript AST and record which specific functions of each package are referenced — default, named, namespace, and member calls.
03
Conservative downgrade
A package is downgraded to "imported but unused" only when its binding is provably never referenced. Dynamic requires, reflection, and indirect calls stay reachable — we never invent reachability.
04
Folds into VaultScore
Unreachable findings are deprioritized in VaultScore (not hidden), so the queue you triage is ordered by what your code actually runs.
What it is — and what it isn't
Function-level (symbol) reachability today covers npm / JavaScript & TypeScript. Other ecosystems (PyPI, Go, Cargo) get import-level reachability but are never downgraded by symbol inspection — they stay unknownrather than risk a false “unused.”
It is deliberately conservative and one-directional: it only ever downgrades a finding when a binding is provably never referenced. A false “reachable” is safe (you just look at one extra finding); a false “unreachable” could hide a real vulnerability, so we never produce one. It is not a full inter-procedural call graph — it's file-local symbol usage, with dynamic/reflective calls treated as reachable.
It needs source to read, so it runs on repo-scanned SBOMs (not lockfile-only uploads). It deprioritizes within VaultScore and never removes a finding from your SBOM.
Triage by what your code runs
Connect a repository, scan it, and let reachability reorder the queue around the functions you actually call.
Frequently asked questions
- What is function-level reachability?
- Most reachability analysis stops at the import level — is the package used at all? SBOMVault goes to the symbol level: which specific functions of each npm package your first-party code actually references. A vulnerability in a function you never call is deprioritized so you focus on exploitable code paths.
- Which ecosystems are supported?
- Symbol-level (function-level) precision is npm / JavaScript & TypeScript today. PyPI, Go, and Cargo get import-level reachability but are never downgraded by symbol inspection — they stay "unknown" rather than risk a false "unused." Full inter-procedural call graphs and more ecosystems are on the roadmap.
- Could it hide a real vulnerability?
- No — that is the core design constraint. Reachability is one-directional: it only downgrades a finding when a binding is provably never referenced, and it always treats dynamic requires, reflection, and indirect calls as reachable. Findings are deprioritized in VaultScore, never removed from the SBOM.
- What does it need to run?
- A repo-scanned SBOM — it fetches and statically analyzes your first-party source (no code execution). Lockfile-only uploads have no source to read. Results fold into VaultScore so every recompute (initial scan, nightly EPSS/KEV crons) stays consistent.