CVE reachability claims are mostly inference. A former CISO grades three vulnerability tool categories, including his own, against one strict standard.
I ran multiple large security programs. I had scanners feeding an RBVM platform, layered with exploit intel. I still pushed thousands of priority vulnerabilities to IT and app teams who pushed back, often correctly. So I borrowed my Red Team and asked a simpler question: which of these can actually be exploited in our environment? They answered it, finding by finding. It worked. It did not scale. Every vendor since has promised to answer that question with a word: reachable, runtime present, truly exploitable in your environment.
The pitch is the same every time: stop patching theater; fix what attackers can actually hit.
That promise is directionally right. The problem is semantic inflation. "Internet reachable," "runtime present," and "high risk score" are useful filters. They are not, by themselves, proof that a specific CVE has an open path from a principal you care about to the vulnerable behavior on a laptop or server.
This post examines three approaches to that question:
Full disclosure: I am now the CEO of Spektion, which exists to automate that Red Team assessment continuously across every endpoint. The third approach below is mine and the bias is named up front. The standard this post sets applies to us too. Grade all three the same way.
In plain engineering terms:
CVE reachability means there is a path from a defined trust boundary to the vulnerable condition for this CVE on this asset (under observed or strongly inferred conditions), and you can show the evidence.
Call that standard path, sink, proof: a path from a trust boundary, to this CVE's vulnerable condition, with evidence you can show. Hold every claim in this post to it, including ours.
That is stricter than:
When a UI badge says reachable or copy says truly exploitable, buyers reasonably assume the strict definition. Products often deliver one or more of the weaker claims.
Reachability is the narrower question: is there an open path from a trust boundary to this CVE's vulnerable condition on this host? Exploitability adds whether that path can be driven to effect: the exploit exists, the conditions hold, controls don't stop it. A finding can be reachable but not yet exploitable. It cannot be exploitable without first being reachable. Most "exploitable" claims skip the reachability proof and jump straight to global likelihood.
Classic vulnerability management matured by admitting CVSS is not a work queue. Marketing and product language shifted to:
Every major scanner now ships a proprietary risk rating built on the same design: combine technical impact (usually aligned with CVSS impact) with a dynamic threat component (recent and predicted exploit activity, weaponization signals, malware kit inclusion) so teams remediate by likelihood of exploit in the near term, not static severity alone. Some blend in asset sensitivity or internet-facing posture from inventory, tagging, or EASM-style discovery.
The EDR-native variants of this category swap the periodic network scan for continuous, agent-visible CVE inventory and AI-flavored exploit-likelihood ranking inside the endpoint agent. Fresher inventory, same data model.
Classic VM is excellent at answering:
"Of everything we found installed, what does the threat landscape say we should fear, on assets we care about?"
It is weak at answering:
"Can someone on the internet (or LAN, or this host) actually drive this CVE's vulnerable behavior here, and what evidence shows that?"
That is not a moral failure of scanners. It is a data model choice: findings are asset × CVE × score, not path × sink × proof.
These platforms sit above the scanners. They ingest classic VM output (and often CNAPP, EDR, firewall, CMDB data), then re-rank. Public positioning across the category is blunt:
The recurring factor list is consistent across the category:
Differentiation vs classic VM is not "we find CVEs." They don't. It is: unify findings, apply context, prescribe mitigations through controls you already own, automate remediation ops. Deployment is typically agentless via APIs: enrichment from tools already deployed, not a new host sensor.
That deployment model is worth sitting with. An aggregation layer has no data of its own. Every signal it re-ranks with was collected by something else, for some other purpose, at some other granularity.
This class does add real prioritization power over raw CVSS queues. Be precise about each factor:
So the category's "exploitable in your environment" is best read as:
That is a better queue than CVSS. It is still mostly not CVE-level path reachability with host evidence (listener, peer class, module load, traffic-gated execution).
If you already run one of these layers, none of this argues for ripping it out. The layer re-ranks whatever findings and context it is fed. The question this post raises is about what sits underneath it: whether the signals are observed on the host or inferred from tags and joins. Prioritization built on inference is not wrong. It is incomplete.
This is where I show my hand, so apply the same skepticism the previous two sections earned.
The first two approaches share a dependency that no scoring model can fix: they rank findings with data collected somewhere else. Classic VM ranks its inventory with global threat intel. Aggregation platforms re-rank someone else's findings with someone else's context, joined over APIs. Neither has an instrument pointed at the thing the reachability question is about: software behaving on a host.
Spektion is built in the opposite direction. One sensor on the endpoint does both jobs. It runs in production across enterprise fleets today.
It detects the vulnerabilities. OS and application CVEs are identified directly from the host, with severity, EPSS, and known-exploitation status attached. There is no scanner feed to ingest and no third-party finding to inherit. Every vulnerability it finds enters the picture through the same observation stream that will judge it.
It observes the conditions that determine whether they matter. Per host, per software, continuously:
This is that Red Team assessment, automated and continuous, on every endpoint.
Here is the shape of the record:
One record, four facts, no score. For what these records look like against a real application, see the WinRAR spotlight: runtime behavior scored the vulnerable versions high before their CVEs existed.
Why detection independence matters for reachability, specifically:
Yes, this means a sensor on the endpoint. Practitioners are right to push back on one more thing to deploy; the deployment and change-control cost is real, and it is a POC question with a measurable answer. So apply the test from this post: does this data exist anywhere else in usable form? Execution state per executable, privilege at runtime, listeners read at the process, components embedded inside applications, recorded on the same record as the CVE they judge. Upstream tools collect fragments of this for other purposes; I never saw an API join reassemble them without losing freshness and identity on the way. And because the sensor detects the CVEs itself, it is not a layer on top of your scanner. It does the detection job and the evidence job in one place.
Observation is half the job. Each risk also generates its own response: step-by-step preventive controls (application control policies, exploit protection settings, GPO) rated for effectiveness and effort, plus detective controls as ready-to-run SIEM queries in standard formats. That output does not depend on a patch existing. For the vulnerabilities you cannot patch this quarter, and the weaknesses with no CVE at all, there is still a concrete action on the record.
Now run Spektion through this post's own weaker-claims table:
That last row matters. Held to the strict definition at the top of this post, no product in any of these three categories delivers the full path object, and I won't pretend we do. We don't run exploits, we don't trace input into a specific vulnerable function. What we do hold, per vulnerable software, per asset, is a piece of each term: the sink side, the vulnerable component present in what actually runs, not just on disk; the path side, that software's own listener, observed at the process; and the proof, timestamped host records of both. The unclaimed piece is the coupling, a trace from input through that listener into this CVE's vulnerable function. And a listener record tells you software, port, and host, not whether that bind is loopback-only or reachable from off the box. A listener is an observed fact; which peers can reach it is still a judgment.
Here is the honest comparison instead. Decompose "is this CVE exploitable here" into its parts: Is the software running? With what privileges? Is it accepting connections? Is the vulnerable component actually present in what runs? What can it reach if compromised? The first two approaches answer those questions by inference, from external data and integration metadata. Spektion answers them with facts recorded on the host where the CVE lives. The inference that remains, coupling a specific CVE's sink to that observed exposure, is explicit, and it starts from evidence instead of a tag. Of these three approaches, that is the shortest distance to the strict definition.
Customers typically cut CVE noise by 50 to 80% when prioritization keys on execution state and observed exposure. That is a smaller number than the category's headline, and it should be: a dismissal only happens when an observed fact supports it. Not running, not privileged, not listening. The difference is auditability, and the range is countable in a pilot; tally your own dismissals and read the fact behind each one. Nobody has to trust a composite score; they can read the evidence behind the verdict.
That matters most when the people doing the patching do not report to you. A ticket that says critical, trust the score gets negotiated. A ticket that says running as SYSTEM, listening on 443, connecting out daily gets scheduled. The is-this-real-on-my-box meeting gets short, because the engineer reads the same fact the ranking used. One customer cut emergency patch events by 60% once tickets carried that evidence.
None of these classes is "lying" in the fraud sense. The first two are selling prioritization using the language of exploitability and reachability: a re-ranking of findings, made from data that cannot settle the question the language raises. Runtime Exposure Management is the one approach of the three where the words and the telemetry mostly point at the same thing, and where the gap that remains is stated instead of scored over.
Enterprise risk still lives heavily on:
Here is where the three approaches diverge on real hosts.
Still not function-level path proof. The difference is that the remaining judgment starts from host evidence instead of tags and scores.
Take these into any demo. Before any demo, run the test on what you already own. Pull ten criticals your current stack deprioritized last quarter and ask what observed fact backs each dismissal. If the answer is a score, you have found the gap this post is about.
When any tool in this space says reachable or exploitable, ask for the evidence object:
Classic VM professionalized prioritization around threat likelihood + asset importance. Aggregation TEM professionalized prioritization around threat + exposure + runtime-ish presence + controls, on top of those same scanners.
Both improved the industry's refusal to treat CVSS 9.8 as a work order. Neither collects the data the reachability question actually requires. One ranks its own inventory with global signals; the other re-ranks borrowed findings with borrowed context.
If the question is "which of these findings can actually be exploited here," the instrument has to watch the environment: what runs, at what privilege, listening where, touching what. Of the three, only Runtime Exposure Management collects that evidence, and only it detects the vulnerabilities from the same observation instead of inheriting another tool's findings and their blind spots. That makes it the strongest basis of the three for a reachability call: the most terms of the question answered by observation, the fewest by inference, and the remaining inference stated where you can inspect it.
Nobody in any of these categories, us included, hands you the complete path, sink, proof object today. The choice you actually have is between reachability scores and reachability evidence. A score implies a path. Evidence records the conditions for one: running, privileged, listening, observed on the host. The five evidence questions tell you which one a vendor is selling. Buy the evidence.
Keep the prioritization layer if it is shrinking your queue. But if the question is what is reachable, start with the tool that watches the software run.
If you want to test this, test it the way this post tests everyone. Bring the five evidence questions to your next vendor review, ours included. Read your own records: what runs, at what privilege, listening where. If our answers sound like a composite score, hold us to the same verdict this post gives everyone else. And if you want the category-by-category version, see how Spektion compares to classic VM and CTEM tools.
Spektion is a runtime exposure management company. Our sensor detects vulnerable and exploitable software behavior, including pre-CVE weaknesses, from runtime telemetry across your endpoints.
Many exploitable weaknesses never get a CVE. Book a runtime exposure assessment and Spektion will show what's actually exploitable across your endpoints.