Dependency reachability
Four gates that cut a dependency scan down to the advisories your code can actually reach.
A dependency scan reports every advisory that touches your lock files. Most of them are not worth an afternoon: the vulnerable function is never called, or the advisory does not apply at your installed version. Dependency reachability decides which ones are.
Enable it with Dependency Check (SCA) → Verify findings reachability on the Static Analysis page. It runs after the Trivy scan; the classic Trivy spreadsheet is produced either way and is unaffected.
Four gates, cheapest first
| Gate | Cost before it |
|---|---|
| 1. Severity | Only critical and high findings continue. Pure data — costs nothing. |
| 2. Reported exploitation | The CVE must appear in the local exploitable-vulnerabilities database. One database query per scan. |
| 3. Applicability | Does the advisory credibly apply to this component at this installed version? One model call per finding. Low scores are dropped before the expensive stage. |
| 4. Reachability | Does your code actually call the vulnerable API? A full agent loop per surviving finding. |
Whatever each gate drops is counted in the scan log and left to the classic Trivy spreadsheet — nothing is silently discarded.
A weaponised CVE in a package your code never invokes is still not reachable. The exploit evidence informs which component functionality to look for; it never decides the verdict.
The exploitation gate
Gate 2 queries the same Vuln table that backs the exploitable vulnerabilities database and the classic Trivy report's "Exploit" column. Presence in that table is the signal: every row there represents a CVE with reported exploitation.
Matching findings gain a Known Exploit column holding the reference URLs, carried through to the HTML report as clickable links and to the XLSX export as newline-separated text.
If the database cannot be queried, the stage stops rather than falling back to verifying every high and critical finding — which would spend an unbounded amount of the scan's AI budget. The scan log names the failure.
What the reachability agent does
The agent runs a tool loop over the repository. Alongside the shared code-navigation tools it has two dependency-specific ones:
| Tool | Purpose |
|---|---|
| find_manifests | Locates manifest and lock files, so the agent can tell a direct dependency from a transitive one. |
| find_package_usage | Searches first-party sources for imports of the package under every spelling it may appear as — registry name, scoped npm specifier, Maven artifact, underscore form, and known divergences such as PyYAML importing as yaml. Vendored and build directories are excluded. |
A verdict is only accepted once the agent has read concrete source files and its rationale names the component, the vulnerable functionality, the call path or the exact broken link, and file:line evidence.
What you get
Every reachable finding carries a Mermaid flowchart tracing the entry point through the import site into the vulnerable component API, rendered inline in the HTML report. Reports are written as depcheck-report.html, .xlsx and .json, and reachable findings are saved to vulnerability management as scan type dependency.
Cost
Every finding that passes the first two gates costs at least one model call, and each survivor costs a full agent loop. Scans of OS package sets can report hundreds of CVEs, which is exactly why the gates are ordered the way they are.
If a scan reports a lot of high-severity OS package CVEs and you only care about your own application dependencies, narrowing the scan scope is cheaper than widening the gates. See AI providers and cost for how token spend is tracked.
Last reviewed 2026-08-16