What the word promises
Exploitability validation is the technical confirmation that a flaw detected on a specific asset can in fact be exploited on that asset, in the state it is in.
A scanner reports that the component version matches a known CVE. That is version matching. Validating is something else: it checks whether the path exists.
The three conditions
A flaw is only exploitable when three things hold at once.
Reachable. The vulnerable component answers from where the adversary stands. A vulnerable library installed but never called by any route is not a path.
Preconditions met. Many CVEs require a specific configuration, prior authentication, or an enabled module. If the precondition does not hold on that asset, the high score means nothing there.
Demonstrable path. A sequence exists that leads from the adversary's position to the described effect. Without it the claim remains a reasonable hypothesis.
Why CVSS does not settle it
CVSS measures technical severity under conditions ideal for the attacker. It describes what would happen if the flaw were exploited, and says nothing about the probability of anyone trying or about your environment.
Two practical consequences show up in any real queue. There are 9.8 flaws published years ago with no known exploit, sitting at the top. And there are medium-scored flaws in active campaigns right now, at position 400 of a list ordered by theoretical severity.
Sorting by CVSS produces a queue whose order bears no relation to risk. The work runs top down, the budget is consumed, and the thing that would take the company down sits untouched in the middle.
The validation rate
Divide the number of findings that went through some exploitability check by the total findings in the period.
In most programs that number sits below 5%. The rest of the queue is raw findings waiting for someone with time to check them one by one, which happens at no team size.
The metric is useful because it does not inflate. A finding count measures the volume a tool produces; a queue of 3,000 unvalidated items and one of 40 validated items can describe the same company, and only the second is executable.
What validation does not do
It does not replace discovery. Validating an incomplete list well anchors the effort to the wrong part of the problem, and produces the most dangerous effect of all: confidence. The company handles everything it knows about very well, closes the quarter on good metrics, and the asset that will take it down never entered the count.
This is why order matters. Discovery first, validation after, over a set that already reflects what exists. That is the sequence continuous threat exposure management organizes into phases, and where CSURFACE's validation operates.