Stage 1 · Scan
Detect CVEs
Standard CVE detection across your dependency tree: npm, pip, maven, gems, Go modules, cargo.
Software Composition Analysis
Traditional SCA flags every CVE in your dependency tree. We pinpoint each advisory's vulnerable function and trace execution paths to find the ones that are actually reachable at runtime: the CVEs the whitebox pentest then tries to exploit.
What traditional SCA misses
Legacy SCA stops at vulnerability identification: it matches lockfile versions against advisories and reports what is present. It never validates whether the vulnerable code can execute. Three checks get skipped.
Which specific function or framework is vulnerable
Pinpoint the function
An advisory typically flags a specific method signature, not the whole package. The actually-vulnerable surface is a small subset of what ships in the library.
Whether your codebase actually uses that function
Check the call sites
Many libraries ship with APIs you never touch. A package can carry a critical CVE in a module your code never imports, and a lockfile scan cannot tell the difference between a real call site and an unused export.
Whether that function is ever actually reached in your code
Walk the path
Even if you call it, dead code, conditional compilation, and test-only paths often keep it from ever running in production. Reachability requires walking the path from a live entry point, not just confirming a syntactic reference.
A typical SCA scan flags hundreds of CVEs. Most point at code that never runs. The reachable ones become exploit targets for the whitebox pentest. The rest is noise.
70-90%
Noise eliminated
Cut from a traditional scan when the three checks run together.
5
Stages
From dependency scan to prioritized verdict. Static CVE lists in, proven executable paths out.
3
Verdicts
Proven Executable, Likely Reachable, or Not Reachable, so triage runs on impact, not lockfile presence.
Those three checks collapse the long tail of lockfile CVEs into a short list your team can actually fix. See how reachability works.
How reachability works
Five stages, from dependency scan to prioritized verdict. A research agent pinpoints each vulnerable function, the Code Property Graph checks whether your code calls it, and execution tracing confirms whether the call path is ever reached.
Reachability analysis, two modes
A CVE in your lockfile is a hypothesis, not a finding. Reachability analysis validates whether the vulnerable code can actually execute in your application, and that evidence determines which dependencies warrant remediation.
Method usage analysis
Mode 01 · Function-level
For function-level vulnerabilities. The Keygraph platform runs data-flow analysis to trace execution paths from your code into the vulnerable dependency function. The report records total paths analyzed, confirmed reachable paths, and unvalidated paths, and each finding cites its sink locations (file, line, code snippet) so reviewers can verify the result themselves.
Library and framework analysis
Mode 02 · Library-level
For library and framework vulnerabilities where code-level data flow isn't applicable. Analyzes how the vulnerable package is imported and used across the codebase, distinguishes production usage from test-only usage, and evaluates exposure conditions and mitigating factors.
| Reachability | CVE severity | Combined risk |
|---|---|---|
NOT_ | Any | Low, regardless of CVE severity |
CONFIRMED_ | High | Elevated to Critical |
POTENTIALLY_ | Medium | Capped at Medium |
One pipeline, the whole surface
SCA is one module on the Keygraph platform. Everything below shares the same findings model, deduplication, and reporting.
Pentesting
Whitebox PentesterCode-aware exploit validation Blackbox PentesterNo source access required Business Logic TestingAbuse of intended behaviour ShannonThe open-source engineSee it eliminate the noise
Schedule a demo and watch reachability-aware SCA run against your dependency tree.