Reachability: is the vulnerable code used?

Many vulnerabilities sit in code your product never uses. Provetry’s CI step, provetry reach, looks for evidence either way and sends suggestions; nothing is decided without your click.

What it can say

• Called by your code (Go with govulncheck, and the languages below): the vulnerable function is reached. The vulnerability moves up.
• Call found in your code (npm and PyPI): a call analysis finds where your code calls a function that leads to the fixed code, with the file and line. The vulnerability moves up.
• Loaded by your code (every language): the vulnerable package is imported, with the file and line. Whether the vulnerable function itself is called is not known at this level.
• Never loaded or never called: suggested as not affected, with the tool’s explanation as evidence. Accept them one by one, or all at once.

For Rust, the function level comes from the functions RustSec names. For npm and PyPI, on the Pro and Consultant plans, your CI also receives the public functions that lead to the fixed code of each advisory, so it can tell “loaded” from “called”.

Where your code names one of those functions, a call analysis then looks for the call itself, through aliases and imports: Jelly (a call-graph analyser from Aarhus University) for JavaScript and TypeScript, a reading of the imports and calls of each file for Python. It only adds evidence: such analyses miss some calls (a function passed as a callback, a re-export), so a call it does not find changes nothing. In CI, Jelly runs with npx; provetry reach --no-calls skips it.

For Java (Maven), the same data covers the public methods that lead to the fixed code. Java libraries also find each other at run time (service loaders, provider files, auto-configuration), so a “never called” needs two more things: the library is a direct dependency of your project, and your build writes its CycloneDX SBOM, which gives the full dependency graph. Add the CycloneDX plugin to the build before provetry reach runs: mvn org.cyclonedx:cyclonedx-maven-plugin:makeAggregateBom (it writes target/bom.json), or the org.cyclonedx.bom Gradle plugin (build/reports/). Without it, Java gets the package level only.

The rule

Every doubt counts as a use. A dynamic import, a macro, a method a framework calls by name: the tool then concludes nothing. And the pipeline only fails on proven calls, never on suggestions.