Reachability and Exploitability: The New Currency of Vulnerability Prioritization

Vulnerability prioritization built on CVSS scores alone is quietly bankrupting security teams’ time and attention. In 2025, researchers tracked 48,185 new CVEs, roughly 131 every single day, and that number keeps climbing year over year. Yet VulnCheck’s 2026 Exploit Intelligence Report found that just 1% of vulnerabilities disclosed in 2025 were confirmed exploited in the wild, even as public proof-of-concept code kept climbing. Put those two facts side by side and the math gets uncomfortable fast: teams are burning cycles patching in severity order when the overwhelming majority of what they’re patching was never going to be touched by an attacker. 

This is the gap that reachability and exploitability close. CVSS tells you how bad a vulnerability could theoretically be. It says nothing about whether an attacker can actually get to it, or whether anyone is bothering to try. Modern exposure management requires pulling apart three distinct questions that have historically been mashed into one severity number: is the asset reachable, is the specific finding reachable through that asset, and is the vulnerability exploitable in practice. Get those three layers right, and vulnerability prioritization stops being a numbers game and starts being a risk conversation.

Why Is Traditional Vulnerability Prioritization Failing Security Teams?

The volume problem alone should be disqualifying. With tens of thousands of new CVEs published annually, no security team, however well staffed, can manually triage its way through the backlog. Even automated scanning tools that surface every match against the CVE database just add to the pile without telling you which finding actually matters.

CVSS was never built to solve this. It’s a severity score: it estimates the technical impact if a vulnerability were exploited, using metrics like attack vector, complexity, and privileges required. What it doesn’t do is account for your environment. A CVSS 9.8 finding on an internet-facing load balancer and the identical CVE on an air-gapped test box in a decommissioned lab get the same score, because CVSS has no concept of where that asset sits or who can reach it. NIST’s own CVSS documentation is explicit that the base score reflects intrinsic characteristics of a vulnerability, not the likelihood or context of exploitation in a specific deployment.

The result is alert fatigue. Security teams chase “critical” after “critical,” patch what’s easiest to patch rather than what’s riskiest, and burn goodwill with engineering teams asking them to drop everything for a finding that, on inspection, was never reachable by anyone outside the corporate VPN. Vulnerability remediation capacity is finite. Every hour spent on a theoretical 9.8 that no attacker could reach is an hour not spent on the exploitable 6.5 sitting on a public-facing API. The fix isn’t a better severity scale. It’s a different question entirely: not “how bad is this,” but “can anyone actually get to this, and are they trying.”

What Are the Three Layers of True Vulnerability Risk?

Real vulnerability risk is a function of three layers stacked on top of each other, not one score. Each layer answers a narrower and more concrete question than the last, and a finding only becomes urgent when all three line up. Miss any one layer and you’re either overreacting to noise or underreacting to a genuine attack path.

Layer 1: Asset Reachability

Asset reachability asks the most basic question first: is this machine, container, or cloud resource actually reachable from a position an attacker could occupy? That depends on network topology, not on the vulnerability itself. A database server sitting behind three layers of firewall rules, tight security groups, and an IAM policy that only permits access from a bastion host is a fundamentally different risk than the same database exposed directly to the internet on a public subnet.

This is where a lot of theoretically severe findings quietly stop mattering. A critical CVE on an internal build server that has no route from the public internet and no route from a compromised endpoint is not zero risk, but it is not urgent risk either. Reachability analysis at the asset level maps every asset’s actual exposure, using real network configuration data rather than assumptions about how the architecture is supposed to work. This is foundational attack surface management: you cannot prioritize what you cannot see, and most organizations are surprised by how much of their environment is reachable in ways the architecture diagram never showed.

Layer 2: Finding Reachability

Asset reachability tells you the front door is unlocked. Finding reachability tells you whether the specific vulnerable component behind that door is actually in the attacker’s path once they’re inside. This is a narrower and harder question. A reachable web server might run a vulnerable library, but if that library’s vulnerable function is never called by the application’s actual code paths, or if the network flow required to trigger it never happens in production, the finding isn’t truly reachable even though the asset is.

This is where attack path analysis and attack tree modeling earn their keep. Instead of asking “does this CVE exist somewhere in my stack,” finding reachability asks “does a realistic sequence of steps exist that gets an attacker from their starting point to this exact vulnerable function or configuration.” A vulnerability three application layers deep, gated behind authentication that isn’t itself broken, is a very different proposition than one sitting on an unauthenticated endpoint. Reachability analysis at the finding level is what separates a CVE that technically exists in your SBOM from one that represents an actual route an attacker could walk.

Layer 3: Exploitability

The final layer asks the question CVSS was never designed to answer: how likely is it that this vulnerability gets used by a real threat actor? This is exploitability assessment, and it draws on three fundamentally different signals that get confused with each other constantly.

CVSS measures severity, not exploitability. It tells you what happens if the vulnerability is triggered, not whether anyone is triggering it. EPSS, the Exploit Prediction Scoring System maintained by FIRST, is predictive: it uses machine learning trained on real exploitation telemetry to estimate the probability that a given CVE will be exploited within the next 30 days. CISA KEV is the opposite of predictive. It’s a confirmed, binary record: a CVE is either on the Known Exploited Vulnerabilities list because CISA has evidence it’s being actively used in attacks, or it isn’t. One forecasts, one confirms, and CVSS does neither. Treating all three as interchangeable severity signals is exactly how teams end up patching the wrong things in the right order.

How Do EPSS, KEV, and CVSS Compare for Assessing Exploitability?

Each of these three frameworks measures something different, and none of them is sufficient alone. Understanding the distinction is the difference between exploitability assessment that reflects reality and one that’s just CVSS with extra steps.

CVSS answers “how bad.” EPSS answers “how likely, soon.” CISA KEV answers “is this already happening.” A CVE can score low on CVSS and still sit on the KEV list because attackers found a creative, low-severity chain to abuse it. A CVE can carry a 9.8 CVSS score and an EPSS exploitability score near zero, because in practice nobody has built a reliable exploit for it. CISA’s KEV catalog remains a small fraction of the total CVE corpus, which underlines just how rare confirmed real-world exploitation actually is relative to the volume of published vulnerabilities.

There’s a fourth piece worth understanding here even though it’s not a scoring system: VEX, the Vulnerability Exploitability eXchange. Where CVSS, EPSS, and KEV all describe a CVE in the abstract, VEX is a standardized, machine-readable way for a vendor or internal team to state whether a specific vulnerability is actually exploitable in a specific product or deployment, using statuses like “affected,” “not affected,” and “fixed.” CISA and NTIA developed the format specifically to solve the SBOM noise problem: an SBOM tells you a vulnerable component exists somewhere in your software, but not whether that vulnerability can actually be triggered in your build. VEX is emerging as the connective tissue between reachability findings and exploitability data, and it’s worth tracking as SBOM mandates expand.

How Can Attack Path Analysis Connect Reachability to Exploitability?

Reachability and exploitability are powerful individually and transformative together, but only if something actually correlates them. This is where most vulnerability management programs fall apart in practice: reachability data lives in one tool, EPSS and KEV feeds live in another, and asset inventory lives in a third, with nobody stitching the three into a single view of which findings form a real attack path to a critical asset.

A Context Risk Graph solves this by correlating findings, assets, network topology, identity data, and business context into one connected model instead of three disconnected data sets. Rather than asking “what’s my CVSS backlog,” it asks the question that actually matters: which findings sit on a path that starts from something an attacker can reach and ends at something the business cannot afford to lose. That path is the unit that matters, not the individual CVE.

This is also where exploitability clusters come in. A single exploitable finding rarely stands alone. It’s usually one link in a chain: a reachable but low-severity misconfiguration that grants initial access, an identity with excess privilege that provides lateral movement, and a genuinely critical CVE with a public exploit sitting at the end of the chain. Attack path analysis surfaces that whole cluster as one connected risk rather than three separate tickets assigned to three separate teams. Fixing the weakest link, often the cheapest fix in the chain, breaks the entire path. That’s a fundamentally more efficient way to reduce risk than triaging a thousand individual findings by severity score, and it’s why organizations that adopt a Context Risk Graph approach tend to report dramatic drops in the volume of findings that actually require action, even as the raw CVE count keeps climbing.

How Can You Operationalize Reachability and Exploitability in Your Security Program?

Understanding the three-layer model is the easy part. Operationalizing it inside a real security program, with real tool sprawl and real headcount constraints, is where most initiatives stall.

Start by moving away from manual, spreadsheet-driven triage. The volume of modern CVE disclosure makes any human-in-the-loop-first process obsolete before it ships. Reachability and exploitability data need to flow automatically from your asset inventory, cloud configuration, and code repositories into a system that can correlate them continuously, not on a quarterly pentest cycle. A scannerless, vendor-agnostic approach matters here specifically because reachability data has to be pulled from every scanner, cloud provider, and identity system you already run, not from one more agent bolted onto your endpoints. Ripping and replacing your existing tool stack to get context is a nonstarter for most security teams, and it shouldn’t be necessary.

This is the problem ArmorCode Platform is built around. ArmorCode is a scannerless, agentic control plane that spans ASPM, risk-based vulnerability management, software supply chain security, and AI exposure management, and it pulls findings, asset data, and network context from the tools you’ve already deployed rather than asking you to stand up new scanning infrastructure. The Context Risk Graph sits at the center of that platform, correlating asset reachability, finding reachability, and exploitability signals from EPSS, CISA KEV, and CVSS into one connected model, so a finding shows up as urgent only when it actually sits on a path an attacker could walk to something the business cares about. Bounded AI workers, ArmorCode’s Anya Agents, then handle the correlation and triage work at the volume this problem actually requires, without operating outside the guardrails a security team sets for them.

Second, feed business context into the model deliberately rather than treating every asset as equally important. A reachable, exploitable finding on a customer-facing payment API and the identical finding on an internal wiki used by three people are not the same risk, even though the technical exploitability score is identical. Application criticality, data sensitivity, and regulatory exposure all belong in the prioritization logic, not bolted on afterward as a manual override. This is the core discipline of exposure management: treating vulnerability data, asset context, and business impact as one continuous pipeline instead of three separate spreadsheets that someone reconciles by hand once a month.

Finally, measure the program by outcomes that matter to the business, not by how many CVEs got closed. Mean time to remediate on the findings that actually sit on exploitable attack paths, and the percentage reduction in the noise that reaches an engineer’s queue in the first place, are both better indicators of program health than a raw patch count. Teams running a mature reachability and exploitability model consistently report that the volume of findings routed to engineering drops sharply once asset reachability, finding reachability, and exploitability are applied as sequential filters, because most of what used to reach a ticket queue never clears the first filter.

The CVE count is not going to shrink. What can shrink is the number of findings your team actually has to act on, and that only happens when reachability and exploitability replace severity as the starting filter. Teams that make this shift stop arguing about which 9.8 to patch first and start asking a better question: which handful of findings, out of tens of thousands, actually sit between an attacker and something that matters. That’s the prioritization model worth building toward, and it’s a substantially smaller list than most security teams currently believe they’re working from.

If you want to see this model working against your own environment rather than a slide, request a demo and walk through how the Context Risk Graph correlates your reachability and exploitability data end to end. Prefer to explore it yourself first? Take a self-guided tour of the platform and see exactly how findings get filtered down before they ever reach an engineer’s queue.