Exploitability has no single meaning. In CVSS it describes how hard a flaw is to attack in general. In VEX it is the name of a status exchange for your product. In the CISA KEV catalog it means exploitation has been observed in the wild. Name which one you mean before you answer an auditor.
Why the word causes trouble
An auditor reads "exploitable" and hears a statement about your system. A scanner vendor may mean a number in a score. A threat feed may mean an attack happened somewhere. All three are honest uses of the word, and they answer different questions.
Mixing them up is how a reasonable record becomes an audit finding. "Not exploitable" on a ticket can be read as a claim that no attacker could ever succeed, when the writer only meant that the CVSS exploitability metrics were low.
The three meanings side by side
| Source | What exploitability describes | About your product? |
|---|---|---|
| CVSS Base metrics | Properties of the vulnerable system that lead to a successful attack | No, generic |
| CVSS Threat metric (Exploit Maturity) | Exploit code availability or in the wild exploitation | No, but time sensitive |
| VEX | Status of your product or component with respect to a vulnerability | Yes |
| CISA KEV | Vulnerabilities CISA tracks as exploited in the wild | No, but a strong signal |
CVSS: ease of attack, in general
The CVSS v4.0 specification says its Exploitability metrics reflect the characteristics of the vulnerable system and the properties of the vulnerability that lead to a successful attack. The v3.1 specification describes them as the ease and technical means by which a vulnerability can be exploited.
These are base metrics, so they do not know your deployment. The specification says the Base score reflects intrinsic characteristics that stay constant over time. Threat and Environmental metrics refine it, and the specification says assessing them is not required but highly recommended.
The Exploit Maturity metric is closer to "is anyone attacking this". The specification says the consumer is responsible for filling it in from threat intelligence.
VEX: a statement about your product
VEX stands for Vulnerability Exploitability eXchange. CISA's minimum requirements describe it as indicating the status of a software product or component with respect to a vulnerability. The statuses include not affected, affected, fixed and under investigation.
A VEX statement is the place where "exploitability" becomes specific to you. For a not affected claim, the OpenVEX specification requires a justification label or an impact statement. See VEX not affected justifications for unreachable code.
KEV: observed in the wild
CISA states that organizations should use the KEV catalog as an input to their vulnerability management prioritization framework. A KEV entry tells you attackers have used the flaw somewhere. It does not tell you your build is affected.
How to word it for an auditor
Say which source you used, then add the local fact.
- Generic severity: "CVSS v4.0 base score as published, not adjusted for our environment."
- Threat signal: "Listed in KEV on the date we checked, or not listed."
- Local fact: "No call path to the affected function found in version 3.2 on the analysis date."
The last line is the one that speaks about your product. Reachability analysis supplies it, and VEX is a standard way to share it.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a generic severity changes once local facts are added.
Quick check
Is a low CVSS exploitability score the same as not exploitable?
No. It describes ease of attack in general. It says nothing about whether the vulnerable code runs in your product.
Does VEX prove a product is safe?
No. It records a supplier's or analyst's claim about status, and the claim is only as good as the evidence behind it.
Safeguard combines reachability analysis with policies and evidence automation, so a status claim can sit next to the record that supports it. You can try the free scan.
Sources
- CVSS v4.0 specification document, FIRST
- CVSS v3.1 specification document, FIRST
- Minimum Requirements for VEX, CISA
- OpenVEX specification
- Known Exploited Vulnerabilities Catalog, CISA
Last reviewed: 19 October 2026.
