The two uses of “exploitability”

My post about a week ago introduced (for those who weren’t familiar with it already) the concept of exploitability of a vulnerability. This term is used in discussions of the risk posed by a particular vulnerability (usually a CVE, although there are other types of vulnerabilities as well). Perhaps the most important reason why the risk posed by a vulnerability comes up is the need to prioritize patches for application. Most medium-to-large organizations today have more patches to apply than they have time in the day to apply them; they need to decide which patches to prioritize and which to ignore. The best way to prioritize patches is to determine how much risk each patch mitigates by assigning a risk score to each vulnerability addressed by the patch.

Risk is a combination of likelihood and impact. Thus, any attempt to measure the risk posed by a vulnerability must take account of both variables. For impact, there isn’t much dispute over the best way to measure that: the well-known Common Vulnerability Scoring System (CVSS) Base Score is an index of the impact (called “severity”) of a vulnerability being exploited in software products in general.

But how can we measure the likelihood that the vulnerability will be exploited? CISA’s Catalog of Known Exploited Vulnerabilities (KEV) is a list of vulnerabilities that are known to have been exploited “in the wild” – i.e., not by a researcher doing a proof of concept, but by a bad guy pursuing not-too-nice ends. It’s hard to argue that any vulnerability in the KEV catalog should be prioritized for patching, since the likelihood that it will be exploited again is close to 100%.

However, the problem with KEV is that fewer than 1% of the 280,000 CVEs in the current CVE list are in the KEV catalog. How can we estimate the likelihood of the remaining 99% of CVEs being exploited in the wild? This is where the Exploit Prediction Scoring System (EPSS) comes in. EPSS is an index of the likelihood that a vulnerability will be exploited in the wild within the next 30 days. In my opinion, a vulnerability risk score should take into account both whether the vulnerability is in the KEV catalog and the EPSS score[i].

However, for a couple of years, I’ve been pointing out that we (meaning the software security community) are now using the term “exploitability” in two senses. One is the EPSS sense, but the other is a sense that I haven’t written about much lately (but used to a lot): VEX. That stands for “vulnerability exploitability exchange”. It’s an outgrowth of the SBOM (software bill of materials) “movement”, which I’ve been involved with. In fact, my book, “An Introduction to SBOM and VEX”, is still the only book on Amazon that seriously discusses SBOMs or VEX (there are a couple of the inevitable books that always appear when a new topic is introduced, offering “5 tips about [insert topic du jour]”. Plus, searching on “SBOM” yields – a few places below my book - one of my kids’ favorite books when they were young, “The Very Hungry Caterpillar”. However, I haven’t figured out what that book has to do with SBOM or VEX).

The idea of VEX came up when a few large companies who were involved in the NTIA Software Component Transparency Initiative, including Cisco and Oracle, became alarmed at the large number of false positive vulnerabilities that appear when a software user utilizes a tool like Dependency Track to identify vulnerabilities in components contained in a product they use; in fact, it seems that more than 97% of the identified vulnerabilities are false positives. This isn’t because the vulnerable code isn’t in the component; it usually is. However, because of the many ways a component can be installed in a software product, in the majority of cases the installation itself mitigates the vulnerability[ii].

Those big companies, driven by visions of their support lines being swamped with calls from outraged users about the huge number of “vulnerabilities” in their products, decided the solution to that problem is a machine readable document that essentially says, “Vulnerability CVE-2025-12345 is not exploitable in our Product ABC version 2.1. You don’t have to worry about it and we won’t patch it, since that would be a waste of both of our time.”

Let’s compare the meaning of “exploitable” in the above sentence and the meaning of the same word in EPSS. In EPSS, a vulnerability is exploitable if there’s an exploit kit available, if it’s being discussed in hacker blog posts, etc. Even more importantly, a lot of different products might be under attack by hackers exploiting that vulnerability; the more attacks that are occurring on more products, the more “exploitable” the vulnerability is. The EPSS score is a probability and varies between 0 and 1.0.

On the other hand, VEX has nothing to do with what’s going on in the outside world. It has to do with a single product, which might be installed on your company’s network or another company’s. It gives a binary answer to the question, “If a hacker were able to reach Product ABC version 2.1 on my network, would they be able to exploit CVE-2025-12345, which is present in a component of ABC v2.1?”

Let’s compare the two uses of “exploitable”. The question in both cases is, “Is CVE-2025-12345 exploitable?”

1.      In VEX, the question refers to a single product. In EPSS, it refers to all products.

2.      In VEX, the answer can be determined by technical means: Ask a hacker of average skill level (not the uber-hacker who could penetrate a brick) to exploit the vulnerability in the product in question (meaning they can utilize the vulnerability for some purpose, like viewing restricted information or escalating privileges). If the hacker can do that, the vulnerability is exploitable in that product. If the hacker can’t do it, the vulnerability isn’t exploitable in the product[iii]. In EPSS, the answer is determined statistically, based on data like the number of times the CVE has been mentioned in a blog or website, and whether there is publicly available exploit code.

3.      In VEX, the answer is binary: the CVE is exploitable in a particular product or it isn’t. The answer doesn’t change unless the product itself changes. In EPSS, the answer is a probability, which changes over time based on changes in the variables that make up the EPSS score (in fact, EPSS scores are re-computed daily for every one of the about 280,000 vulnerabilities currently in the CVE catalog).

4.      In VEX, the skill level of the hacker can make a big difference in the answer to the question whether CVE-2025-12345 is exploitable in Product ABC v2.1. If the hacker is very skillful, they might be able to compromise ABC. This is why VEX assumes a certain “average” level of hacker skill, although that can never be specified with any rigor. On the other hand, EPSS just depends on activity. If enough hackers are trying to use CVE-2025-12345 to attack any product, it doesn’t matter whether they’re succeeding in their efforts. If hackers are targeting that vulnerability, its EPSS score will probably go up.

Given how differently the single term “exploitable” is used in the two cases, it seems clear both cases shouldn’t use the same term. I think the VEX use case is more deserving of the term, since the question is whether it’s technically possible for any hacker to exploit the vulnerability in that product. The answer to the question in the EPSS use case doesn’t depend on technical data. Instead, it depends on statistical analysis of social data, such as the existence of code to exploit the vulnerability, or even just public discussion about doing so.

However, even though I think the VEX use case is much closer to what most security professionals think of when they use the term “exploitability”, I admit it’s too late to try to take it away from the EPSS use case. The VEX concept is struggling to be accepted, while EPSS is already in wide use. What should we do? Call the EPSS case “Exploitability #1” and the VEX case “Exploitability #2”?

That won’t work, but there’s another way we can state the fact that an attacker of medium skill should be able to exploit the vulnerability in the product in question: We can say, “Product A version 2.1 is affected by CVE-2025-12345”, rather than “CVE-2025-12345 is exploitable in Product A v2.1.” In fact, this is the wording we use to talk about vulnerabilities in general today. I suggest we use this wording when discussing VEX use cases from now on. Problem solved.

If you would like to comment on what you have read here, I would love to hear from you. Please email me at tom@tomalrich.com.

My book "Introduction to SBOM and VEX" is available in paperback and Kindle versions! For background on the book and the link to order it, see this post.

---

[i] EPSS scores for all 280,000 CVEs in the current CVE catalog are updated daily.

[ii] There are many other reasons why a vulnerability in a component will not be exploitable in the product itself – e.g., if the developer patched the vulnerability when it installed the component in the product.

[iii] For us to make the positive statement that the vulnerability is exploitable in the product, Mr./MS Average Hacker would have to succeed in exploiting the vulnerability. However, if the same hacker can’t exploit the vulnerability once, that doesn’t demonstrate the vulnerability isn’t exploitable. The hacker would have to fail to exploit the vulnerability multiple times, before it could be said that the vulnerability isn’t exploitable in the product.