Reachability & Exploitability: Why "Critical" Usually Isn't

A scanner drops a CVSS 9.8 into your backlog and everything stops. Someone escalates. A sprint gets reshuffled. Two days later you find the vulnerable function is never called anywhere in your codebase. It was never a 9.8 to you - it was a 0.

This happens constantly, and it's the single biggest reason AppSec backlogs are both enormous and untrustworthy. The severity score attached to a vulnerability describes the vulnerability. It says nothing about your application. And "critical in theory" is a very different thing from "critical here."

What CVSS actually measures

CVSS is a rating of a vulnerability in the abstract - how bad it could be under worst-case assumptions, independent of where it lives. That's genuinely useful as a common language. It's a terrible way to order your to-do list, because it deliberately ignores the two things that decide whether a vulnerability matters to you: can the code even be reached, and can it actually be exploited in your setup.

Rank your backlog by CVSS and you get a queue where a 9.8 in dead code sits above a 6.5 sitting on your internet-facing checkout flow. That's backwards, and everyone who's triaged findings knows it.

Reachability: can you even get there?

Reachability analysis asks whether a real execution path exists from input an attacker controls to the vulnerable code. It's the first and cheapest filter, and it's brutal in a good way.

A huge share of dependency findings fail it immediately. You pull in a library for one function; the CVE is in a different function you never touch. SCA flags the whole package as vulnerable because the version matches - but if nothing in your code reaches the vulnerable path, an attacker can't reach it either. In real codebases, reachability alone routinely removes the majority of "critical" dependency findings from consideration.

The same logic applies to first-party code. A dangerous function guarded behind a code path that no input can trigger is not an open door. It's a door with no hallway leading to it.

Exploitability: can it actually be done?

Reachable isn't the same as exploitable. Code execution might reach the vulnerable line, but input validation, framework behavior, or existing controls can still make the attack fail in practice. Reachability narrows the field; exploitability confirms the survivors.

The honest way to establish exploitability is to attempt it - the way a penetration tester would - rather than to infer it from a base score. A finding that can be triggered and shown to cause harm is worth blocking a release over. One that's reachable but can't actually be exploited belongs in a tracked, low-priority list, not on fire in your dashboard.

Reachability decides risk. The exploitable function on the live path is the one that matters; the CVSS 9.8 with no path leading to it doesn't.

What changes when you prioritize this way

Run a real backlog through reachability and exploitability and the shape of it changes completely. The thousands-long list of "criticals" collapses into a short list of issues that are reachable, exploitable, and sitting somewhere that matters. That list is short enough to fix, and credible enough that nobody argues with it.

It also flips a conversation every security team has lost at some point. When engineering asks "why is this blocking my release?", the answer stops being "the scanner said critical" and becomes "here's the path, here's the exploit, here's what it touches." That's an answer people act on instead of resent.

CVSS tells you what a vulnerability could do to someone, somewhere. Reachability and exploitability tell you what it can do to you. Defenzon prioritizes on the second question - because that's the only one your release actually depends on.

FAQ

What is reachability analysis?

Reachability analysis determines whether there's an actual execution path from attacker-controlled input to a vulnerable piece of code. If the vulnerable code can't be reached, the vulnerability generally can't be exploited in that application.

Why isn't CVSS enough to prioritize vulnerabilities?

CVSS scores a vulnerability in the abstract, independent of your environment. A high CVSS in code you never call is low risk to you, while a medium CVSS on an exposed, reachable path can be your biggest problem. Context beats the base score.

What's the difference between reachable and exploitable?

Reachable means code execution can get to the vulnerable code. Exploitable means an attacker can actually trigger the vulnerability to cause harm. Reachability is a prerequisite; exploitability is the confirmation.

See how Defenzon ranks risk by what's reachable and exploitable, not by CVSS alone.

Book a demo