If you run software composition analysis (SCA) at any scale, you know the problem isn't finding vulnerabilities—it's finding the ones that matter.
A typical dependency tree pulls in hundreds, sometimes thousands of packages. Scan that tree against the CVE database and you'll get a backlog that no team can realistically work through: most of it in code paths your application never executes. Triage becomes a full-time job, “critical” loses its meaning, and the vulnerabilities that actually put you at risk get lost in the noise of the ones that don't.
Today, we're announcing Vulnerability reachability, now available in SonarQube Advanced Security it answers the one question a CVSS score never could: does your code actually call the vulnerable function?
The threat landscape is changing
Frontier AI models can now find and weaponize vulnerabilities on their own, at a speed no patch cycle was built to match. The window between a vulnerability existing and it being actively exploited keeps shrinking, and what used to take attackers weeks now takes hours. Conducting a post-release audit or maintaining a backlog of thousands of unranked CVEs waiting for manual triage are no longer viable strategies against that timeline.
That makes prioritization the whole game. When the exploit window is measured in hours, security teams can't afford to spend those hours investigating vulnerabilities their code never even touches. Knowing which risks are confirmed reachable, and fixing those first, is how teams keep pace with a threat landscape that no longer waits for a quarterly patch cycle.
What is vulnerability reachability analysis and how does it work?
For every vulnerability detected in a third-party dependency, SonarQube now performs a call graph analysis of your codebase to determine whether your code calls the specific functions associated with that vulnerability. The result is one of three reachability states, shown directly on the dependency risk card and available as a filter across your “Dependency Risks” view:
- Reachable: SonarQube found your code calling functions associated with the vulnerability. Treat these as your priority queue.
- Unreachable: SonarQube found no instances of your code directly calling the vulnerable functions. Worth noting: you may still be exposed through transitive calls from other dependencies, or other exploitation paths reachability analysis currently doesn't cover. This status lowers the threat, it doesn't clear the risk.
- Not analyzed: Reachability hasn't been calculated yet, whether because the vulnerability is in a currently unsupported language, the vulnerable package is a transitive dependency, or deep vulnerability analysis hasn't run yet.
Reachable vulnerabilities should go to the front of the remediation line. That's the whole point: instead of a flat list ranked only by severity, you get a signal grounded in what your code is actually doing.
What factors should I use to prioritize CVEs beyond CVSS scores?
Reachability is the newest input into how Sonar scores a dependency risk, alongside the factors you're likely already using:
CVSS, KEV, and EPSS all describe the vulnerability in the abstract. Reachability is the one factor that's specific to your codebase—and it's often the difference between a blocker-severity CVE that's genuinely urgent and one sitting in a code path you never call.
How does SonarQube determine if a vulnerability is exploitable in my code?
Reachability requires a full call graph of your code, which means it's only calculated during a full analysis, run in CI or via automatic analysis, rather than during continual analysis. If a vulnerability is first surfaced through continual analysis, it'll get its reachability status at the next full analysis run.
At launch, reachability analysis is supported for vulnerabilities in Java, C#, and Python code. Call graph analysis is a genuinely hard problem to do well across languages with different dependency resolution models, dynamic dispatch behavior, and build tooling, so we'd rather ship it accurately for a focused set of languages first than ship shallow coverage everywhere at once. Additional language support is on the roadmap.
Where you'll see vulnerability reachability
- “Dependency Risks” tab: filter by “Reachability” to instantly surface confirmed reachable vulnerabilities, and spot the “Reachable badge” on individual risk cards.
- “Detailed Risk” view: reachability status sits alongside CVSS, EPSS, and KEV data in the “What's the Risk?” tab, so you get the full picture in one place.
- Reports: reachability status is included in downloadable dependency risk reports (JSON/CSV), so the same signal that drives your team's triage can also back your compliance attestations. (Enterprise plan only)
- SonarQube Remediation Agent: reachable vulnerabilities are exactly the ones worth automating. If you're a Remediation Agent subscriber, let the agent open a pull request that bumps the affected dependency to a fixed version, and spend your team's attention on the harder cases instead.
Why vulnerability reachability matters now
Every SCA tool can tell you a dependency is vulnerable. Far fewer can tell you whether that vulnerability is something an attacker could actually trigger through your code, and that gap is exactly where alert fatigue comes from. As dependency trees keep growing, and as attackers (increasingly AI-driven ones) close the gap between disclosure and exploitation, “confirmed reachable” becomes one of the few triage signals that scales.
Reachability doesn't replace CVSS, KEV, or EPSS. It sits on top of them, narrowing thousands of theoretical risks down to the ones your code can actually reach, so your team fixes what matters first and stops re-litigating the rest.
Get started
Vulnerability Reachability is available now to SonarQube Advanced Security customers on SonarQube Cloud and SonarQube Server, for Java, C#, and Python projects analyzed in CI. No extra configuration is required: reachability status will start appearing on your existing dependency risks after your next full analysis.
To dig into the details, see Reviewing and fixing dependency risks in the SonarQube Cloud. documentation.
Start prioritizing by what's actually reachable. Request a free trial of SonarQube Advanced Security, or see plans and pricing.