Attack-path graph
The attack-path graph connects a vulnerable dependency to the place an attacker could actually reach it — from an HTTP entry point, through your call graph and dependency tree, to a dangerous sink. Paths are scored so you fix the few that are genuinely exploitable, not the thousands that aren't.
The idea
A CVE deep in a transitive dependency only matters if there is a path from untrusted input to the vulnerable code. dpndncY builds a unified graph from three layers:
- Entry points — routes/handlers that receive untrusted input (from the SAST source model).
- Your call graph — functions calling functions (from the SAST data-flow engine).
- The dependency tree — your code into direct and transitive packages (from SCA).
It then finds paths that start at an entry point and end at a vulnerable sink inside a flagged dependency.
Scoring
Each path is scored so the riskiest float to the top. Inputs to the score:
| Factor | Effect |
|---|---|
| Reachability | Is the vulnerable symbol actually called? Unreachable paths are de-prioritised. |
| Sink class | exec / SQL / deserialise weigh more than, say, a log sink. |
| CWE severity | Higher-impact weaknesses raise the score. |
| Exploit signal | KEV / EPSS / ExploitDB on the underlying CVE amplify it. |
| AI-code amplification | Paths passing through AI-generated code (see AI risk) are weighted up. |
Sink catalogue
Sinks are the same catalogue the SAST engine uses: command/code execution, SQL/NoSQL, file read/write & path traversal, network/SSRF, deserialisation, template injection, and redirect.
Using it
- UI — an interactive force-directed graph; click any node to see the path and the evidence.
- API — query reachable paths for a given package or finding to wire into your own triage.