Reachability
Many alerts on your dependencies are about code your product never runs. Provetry shows you which, with the evidence.
Under the Cyber Resilience Act, every known vulnerability in a supported release needs an assessment. Assessing them one by one, by reading code, is where the time goes. Provetry looks for evidence either way, in your own CI, and hands you the answer with its proof.
Three answers, each with its evidence
Never loaded
The vulnerable package is in your lock file, but no path leads to it from your code. Provetry gives the chain that brings it in, and suggests "not affected: the component is never loaded".
Loaded, never called
Your code loads the package, but never names the functions that lead to the vulnerable code. Provetry lists those functions, and suggests "not affected: the vulnerable code is never run".
Called
Your code reaches the vulnerable code: the vulnerability moves up the list, with the file and the line. On request, your pipeline fails on it.
What you see in the app
flat@5.0.0 · directPrototype Pollution in flat
Imported by your code (web/src/config.js:2), loaded by nothing else
Suggested: not affected — the vulnerable code is never run
The function that leads to the fixed code (unflatten) is named nowhere in the repository.
What is covered
| Ecosystem | Package level | Function level | From |
|---|---|---|---|
| Go | Yes | Yes | govulncheck |
| Rust (Cargo) | Yes | Yes | The functions RustSec names |
| JavaScript and TypeScript (npm) | Yes | Pro and Consultant | Provetry’s vulnerable-functions data, and the Jelly call analysis |
| Python (PyPI) | Yes | Pro and Consultant | Provetry’s vulnerable-functions data, and a reading of the calls |
| Java (Maven) | “Loaded” evidence only | Pro and Consultant, for direct dependencies, with your build’s CycloneDX SBOM | Provetry’s vulnerable-functions data |
| PHP, Ruby, .NET | Yes | Not yet | — |
Results reach Provetry from your CI with an API key, on the paid plans.
The vulnerable-functions data
Most advisories name a package and its versions, not the functions at fault. Every day, Provetry reads the fix of each reviewed advisory, finds the functions it changed, then the public functions of the package that lead to them. That is what lets your CI tell "loaded" from "called". It is served to Pro and Consultant customers with their API key.
How it runs
In your CI, on your code
The open-source core runs in your pipeline (GitHub Action, GitLab template). Your source code never leaves your infrastructure: Provetry receives the results, not the code.
Suggestions, never decisions
Every "not affected" is a suggestion with its evidence. You accept it, one by one or all at once, and it becomes your VEX assessment, published if you choose.
Every doubt counts as a use
Where it sees a dynamic import, a call by reflection, a macro, a method a framework calls by convention or a file too large to read, the tool concludes nothing. A false "never called" is the mistake it is built to avoid above all.
Recorded as evidence
Accepted assessments go into your evidence journal, chained and time-stamped, ready for a market surveillance authority.
The limits, said plainly
- The function level reads names, not types: a function your code names counts as possibly called, even when it is not. For npm and PyPI, a call analysis then looks for the call itself and, when it finds it, shows the file and the line; when it does not, the mention stays, because such analyses miss some calls. Like any analysis of code, it cannot see a call made in a way it does not know.
- A fix can change more than the vulnerable code, and an advisory may link no fix: then there is no function-level answer, only the package level.
- Java libraries also find each other at run time (service loaders, provider files, auto-configuration). A "never called" is only given for a direct dependency, from the full dependency graph your build writes, and never when generated code (Lombok, MapStruct…) or vendored jars may call it.