Reachability and exploitability: which vulnerabilities actually matter

If you monitor the SBOMs behind your software, you have probably seen the list grow faster than anyone can work through it. A new CVE is disclosed, it matches a package somewhere in your dependencies, and another finding lands in the queue. Most of those findings are real vulnerabilities. Very few of them are real risks to your product.

The gap between “this vulnerability exists in a package we use” and “this vulnerability can actually hurt us” is where reachability and exploitability come in.

What reachability means

A vulnerability lives in a specific function or code path inside a dependency. Your application pulls in that dependency, but it almost never uses all of it. Reachability is a simple question with a useful answer: can your own code actually get to the vulnerable part of the package?

If your code never calls the affected function, directly or through other functions, the vulnerability sits there unused. It is still worth patching eventually, but it is not an emergency. If your code does reach it, that changes the priority.

Reachability turns “we depend on a package that has a CVE” into “our code does, or does not, touch the vulnerable part.”

What exploitability means

Reachability tells you whether the vulnerable code can be reached. Exploitability asks the next question: given how you actually use it, could an attacker take advantage of it?

A function can be reachable but still not exploitable in your context. Maybe the input that would trigger it never comes from an untrusted source. Maybe a guard upstream rules it out. Exploitability is the judgment that puts reachability in context, so you are not just asking “can this run” but “does this matter the way we use it.”

Put the two together and a long, flat list of CVEs becomes something you can act on: the findings that are reachable and exploitable rise to the top, and the ones that can never be triggered stop competing for your team’s attention.

Why most findings are noise

This is not a knock on your scanners. A good scanner is supposed to report every known vulnerability in every component it finds. That is its job. The problem is what happens next: a person has to decide, finding by finding, whether each one matters.

Done by hand, that means reading advisories, opening code, and tracing call paths, over and over, while everything else your team needs to ship waits. When every finding looks equally urgent, the genuinely dangerous ones are harder to spot, not easier. Reachability and exploitability give you a way to cut the list down to the ones worth a closer look.

Build-time source analysis, not runtime

There is an important distinction worth getting right. Reachability can be worked out two very different ways.

One way watches your application while it runs and records what actually executes. That is runtime analysis, and it needs something installed alongside your software.

The other way reads your source code and follows how your code connects to the vulnerable package, the same way you would if you were tracing it by hand, only faster and over far more findings. That is build-time source analysis. It does not run an agent on your servers and it does not watch live traffic. It reads code.

Build-time source analysis is a good fit for triage because you can run it as findings arrive, before anything ships, without touching production.

How Quaze approaches it

Quaze proposes a reachability and exploitability verdict for each finding. Reachability starts with a deterministic pass over your import and dependency graph. When the graph can settle a case on its own, the verdict is labelled graph-derived. When it cannot, AI source-code analysis reads the relevant first-party code and the verdict is labelled AI-inferred. Either way, the verdict comes with a confidence score and cites the files and lines it is based on, so you can check the reasoning rather than take it on faith.

A few things are worth being clear about:

• It is opt-in and off by default. An owner connects a source repository and turns it on.
• It proposes; people decide. The analysis never sets a finding’s status or overrides a human triage decision on its own.
• You can run it with your own API key, or use Quaze managed AI, which runs EU-region inference so your data and the analysis both stay in the EU.

The point is not to replace your judgment. It is to do the slow first pass for you, so the time your team spends goes to the findings that are actually reachable and actually exploitable.

Turning the answer into evidence

Once you have triaged a finding, the reasoning behind it is worth keeping. Quaze carries the reachability and exploitability evidence with each decision and can export it as CycloneDX VEX, the standard way to tell the people who consume your software which vulnerabilities do not affect it, and why. That same record supports your Cyber Resilience Act preparation.

A long list of CVEs was never the goal. Knowing which ones can actually reach you, and being able to show your work, is.