Sharpen your Spear: Prioritizing Vulnerabilities Beyond CVSS & KEV

Summary

There are now far more CVEs than any organization can patch, so security teams need a way to decide which vulnerabilities to fix first. In this session, Omer Tal, Director of Innovation at Seemplicity, compares the main prioritization frameworks. CVSS measures impact but is static and skews toward worst-case scores. CISA’s KEV catalog confirms real-world exploitation but covers only a small set of CVEs. EPSS predicts exploitation in the next 30 days but says nothing about impact. SSVC adds asset context but is hard to automate. His recommendation is to combine these signals with a simple high-risk versus normal-risk view of your assets, express the result as priorities such as P0 to P5 rather than severities, and automate and tune the model for your own environment.

Key takeaways

• New CVEs jumped from about 5,000 a year to more than 20,000 after the CVE Numbering Authority program expanded in 2016, so patching everything is no longer possible.
• CVSS is the only framework that measures impact. The attack vector, user interaction, and integrity values together show whether a vulnerability is a remote code execution (RCE) risk.
• KEV catalogs from CISA and VulnCheck list vulnerabilities with evidence of real-world exploitation. The lists are short enough that reaching zero KEVs is achievable, and it should be a goal.
• EPSS predicts the chance of exploitation in the next 30 days and covers every CVE, but it doesn’t measure impact and can miss vulnerabilities already being exploited.
• Add asset context by flagging high-risk assets automatically: internet-exposed systems, crown jewels, and end-of-life systems.
• Use priorities (P0, P1, P2) instead of severities. They map to remediation SLAs, are easier to communicate, and are easier to tune.
• Leave room for “celebrity CVEs,” like regreSSHion in OpenSSH, that warrant immediate action even when their scores don’t.

This webinar was recorded in 2025. Scores and statistics cited reflect that time.

Why can’t organizations patch every vulnerability?

Omer Tal, Director of Innovation, Seemplicity: Welcome to my talk, “Building on CVSS, EPSS, and KEV: A Practical Approach to Vulnerability Prioritization.” A few words about me: my name is Omer, and I’ve been doing security research for more than a decade. Today, I work at Seemplicity, where we’re building an AI-powered remediation operations platform for exposure management. Before that, I worked at other cybersecurity startups, so this is basically what I’ve been doing my entire career.

To begin, let’s talk about how we got here. How did we reach a point where we need to spend 30 minutes talking about vulnerability prioritization? Up until 2016, the situation was pretty stable. This graph shows the number of new CVEs published each year. It’s not the total number of CVEs; we now have about 300,000 vulnerabilities in total. This is just new CVEs per year. Until 2016, we had roughly 5,000 new vulnerabilities each year, and then something changed: the CNA program expanded. CNA stands for CVE Numbering Authority, a program that lets vendors list their own vulnerabilities. Basically, since 2016, anyone can list a new vulnerability, and the number immediately jumped to 20,000 a year. Since then, the number of new CVEs has grown exponentially, which means the total number of CVEs is growing even faster.

So we have too many CVEs to patch them all. No organization today can reach zero vulnerabilities. Maybe that was possible before 2016, but it’s not possible now. If it’s impossible to remediate every vulnerability, we have to answer the question: which vulnerabilities should I remediate first? Until 2020, we had one way to prioritize vulnerabilities, and that was CVSS. Because of the growing number of vulnerabilities, we’ve also seen a growing number of frameworks, scoring systems, and methods for prioritizing them. So today we have far more vulnerabilities than we can ever remediate, far more parameters to consider than before, and no more people to do the work. Security teams didn’t grow exponentially too.

So today, we’ll talk about which frameworks exist for prioritizing vulnerabilities, their pros and cons, and how to turn them into a practical approach that fits your organization.

What are the strengths and weaknesses of CVSS?

Let’s start with CVSS: the first, the most famous, and the one everybody loves to hate. If you Google CVSS today, it’s easier to find articles about why you shouldn’t use it than about how or why you should. You’ll see articles like “Why the Common Vulnerability Scoring System Sucks” and “Five Reasons to Stop Using CVSS.” Is CVSS really that bad? It has some serious caveats we need to discuss, but it also has strengths you can’t take away from it.

The first is coverage. Almost every CVE has a CVSS score, which is very useful and isn’t necessarily true of the other scoring systems we’ll discuss. The second pro is that it’s the only scoring system that tries to measure the impact of a vulnerability: what it can do once it’s exploited.

The complaints people usually make about CVSS fall into two categories. The first is that scores are very subjective and are often based on the worst-case scenario. For example, if a vulnerability could theoretically become a remote code execution, or RCE, it might be scored and classified as an RCE, because everything assumes the worst. That creates a lot of false positives. There aren’t many false negatives, though: if a CVE gets a low CVSS score, it’s usually genuinely not interesting. But a 9.2 or a 10 doesn’t necessarily mean the CVE is that important. It means it has the potential to be risky.

The second complaint is that the CVSS score is static. A vulnerability gets its score once it’s analyzed, and that’s its score. It doesn’t reflect the current state of exploitation. When a CVE is first published, there may be no viable exploit yet, and if no one in the world knows how to exploit it, it isn’t such a high risk yet. But there are different kinds of exploits: complicated exploits, proofs of concept, and easy exploits in Metasploit that you can launch with a double-click. Once a vulnerability has that kind of exploit, it’s far more dangerous, and CVSS doesn’t consider that at all.

How can CVSS vectors identify remote code execution vulnerabilities?

It’s important to understand that CVSS isn’t just a score. It’s not someone saying, “This looks like a 9.2 to me.” CVSS is composed of vectors. An analyst, usually from NVD or from the vendor that reported the CVE, chooses all of these attributes for the CVE, and the CVSS score is calculated from them using documented formulas. CVSS is a public asset: you can find the formulas and all the documentation on first.org, and the scores themselves are public in NVD, the National Vulnerability Database.

These attributes let you understand what a vulnerability can do, according to whoever analyzed it. By isolating three of them, attack vector, user interaction, and integrity, you can tell whether a vulnerability is an RCE, which helps cut through the noise in CVSS scores. Attack vector “network” means it’s a remote vulnerability. User interaction “none” means the user doesn’t have to do anything to be attacked. And integrity “high” means an attacker using this vulnerability can gain full control of the target machine. Those three attributes alone tell you whether the vulnerability is an RCE, which is a useful thing you can do with CVSS beyond looking at the scores.

What is the KEV catalog, and how should you use it?

Now let’s talk about another way to prioritize vulnerabilities: KEV. KEV, from CISA, stands for Known Exploited Vulnerabilities. It’s not exactly a scoring system or a prioritization framework. It’s a catalog: a list of vulnerabilities, reviewed by CISA, a government agency, that have real evidence of exploitation in the wild. Maybe an organization reported to the government that it was attacked using a vulnerability, or an organization defending against it reported live exploitation, not in a lab or as a proof of concept, but real attackers attacking real machines.

Why is this important? If you’re exposed to a vulnerability that’s already on this list, someone bad out there knows how to exploit it. If you still have that vulnerability, you could be exploited next.

CISA isn’t the only one maintaining a KEV catalog. VulnCheck, a threat intelligence company, maintains another one called VulnCheck KEV, and its list is bigger than CISA KEV. Every CVE in CISA KEV is also in VulnCheck KEV, along with many more; VulnCheck’s list is three to four times bigger. Why? Their threshold for entering the list is a bit lower. They’ll accept somewhat less evidence and add any CVE that has enough of it. CISA tries to keep its list short and meaningful to government agencies and government interests, so it focuses on vulnerabilities in products common in large organizations and government agencies, like Microsoft, Atlassian, and Apple.

So what are the pros and cons of using KEV catalogs for prioritization? The biggest pro is verified threats. There are no false positives: every KEV is a real threat and something you should fix immediately. The second pro is that the list is short enough to be very actionable. We started by saying it’s impossible to remediate every vulnerability, but it is possible to remediate every KEV, because the list is so short: roughly 1,500 to 4,000 vulnerabilities, depending on which list you use. Reaching zero KEVs is very achievable, and every organization should aim for it, because if you’re exposed to a KEV, you could be attacked next. Someone out there is looking for that vulnerability and knows how to exploit it.

The cons of KEV start with limited scope. It only tells you about vulnerabilities that not only have an exploit, but are already being exploited, and sometimes that’s too late. If you only remediate KEVs, you’ll always be late, because for a vulnerability to enter the catalog, it had to be exploited somewhere first. Some organization had to take one for the team, and that organization might be yours. It tells you about the critical CVEs you have to fix immediately, but nothing about the other 300,000 vulnerabilities out there. The second con, as I said, is that CISA KEV is focused on government interests and doesn’t cover every exploited vulnerability. The VulnCheck KEV list can help cover that gap, so use both. Both are free, public, and have APIs that anyone can use to download them daily.

What is EPSS, and where does it fall short?

Now let’s talk about EPSS, the Exploit Prediction Scoring System. It’s a machine learning model trained to predict which vulnerabilities will be exploited in the next 30 days. How does it work? It feeds many parameters into the model: the CVSS score, the vendor (because some vendors’ products get exploited faster than others), how many people are talking about the vulnerability in blogs and forums, whether there’s anything in Metasploit, and so on. All of that goes into a model trained to predict exploitation in the near future. The model isn’t always right. It’s not an oracle and can’t predict the future, but it correlates well with whether a vulnerability is actually exploited in the next 30 days.

The pros: every CVE has an EPSS score, because the model runs automatically every day on all CVEs, which is very useful. And it offers a real prediction of exploitation.

The cons: EPSS itself has no impact assessment. The EPSS score is a number between zero and one that tells you the chance of exploitation in the next 30 days. For example, 0.7 means the model predicts a 70% chance of exploitation in the next 30 days. It doesn’t tell you anything else about the vulnerability, such as what it will do once it’s exploited. Is it an RCE? A data leak? A denial of service? That said, there is a strong correlation between CVSS and EPSS scores: the higher the CVSS, the higher the EPSS, which makes sense, because attackers usually exploit the vulnerabilities with more impact. So EPSS alone doesn’t tell you about impact, but it correlates with it.

The second con is that the model is heavily focused on the next 30 days and can be a bit blind to the past, which leads to some false negatives. For example, this CVE is already in CISA KEV, meaning someone has definitely exploited it; you can’t enter CISA KEV without evidence. But its EPSS score was 0.0008, which suggests essentially no chance of exploitation in the next 30 days. As I said, remediating KEVs is something you should do no matter what EPSS, CVSS, or any other framework says. So EPSS has blind spots, like every other framework. EPSS also has a free API for downloading daily scores, with documentation on first.org. All of these frameworks are free and public.

How do CVSS, EPSS, and KEV compare?

So we’ve covered three frameworks: CVSS, EPSS, and KEV. CVSS and EPSS both have good coverage; they cover all CVEs. KEV doesn’t, because it only covers known exploited vulnerabilities, so it tells you nothing about the rest. EPSS offers good prediction of the future, KEV offers good evidence from the past, and CVSS is the only one that addresses impact: what a vulnerability can do once it’s exploited. Each one has blind spots and strengths, and if we use them together, we can take advantage of each one’s strengths and cover the others’ blind spots. We’ll get to that soon.

What is SSVC, and why is it hard to scale?

Before that, I want to talk about another framework that’s often mentioned: SSVC. It’s a bit different from the others, because it isn’t a score you can download. SSVC is more of a documented, theoretical approach to how an organization should prioritize vulnerabilities. It’s also offered by the government, and it stands for Stakeholder-Specific Vulnerability Categorization. It’s a decision tree. You start by asking whether the vulnerability has an exploit, for example, active exploitation, a proof of concept, or none. Either way, you move to the next decision point, how automatable the exploit is, and then to impact. That covers everything we’ve discussed: both exploitation and impact.

The other decision point is one every organization has to consider when prioritizing vulnerabilities: asset context. The same vulnerability, whether or not it has an exploit, isn’t the same risk on an internet-facing production server as on a lab server that isn’t accessible from anywhere. Machines exposed to the internet carry more risk. Machines with sensitive data carry more risk. Even with the same CVE, you don’t have to treat every instance the same. SSVC is the only framework that tries to measure asset context: what’s specific to this stakeholder and this particular vulnerability finding. You get that in the last decision point, called “mission and well-being,” and SSVC includes a lot of documentation on how to choose it.

And that’s the problem with SSVC. It’s good in theory, a full, holistic way to prioritize vulnerabilities, but it’s not something you can automate and scale, and it’s not easy to run. Some organizations have millions of open vulnerabilities, and SSVC isn’t something you can just download and run across all of them. It’s mostly theoretical, which is why I don’t recommend it for every organization. So what can we do in the practical world, where we want to use all these frameworks and bring asset context into our prioritization model?

What are “celebrity CVEs,” and how should you handle them?

Let’s demonstrate these frameworks with a specific CVE. I took regreSSHion, a famous CVE from July 2024. It was the first RCE in OpenSSH in years, and it generated a lot of noise online when it was published; everyone was talking about it. It was called regreSSHion because the vulnerability had been discovered a decade earlier, patched, and then reintroduced into the code.

I checked this vulnerability a week after publication, back in 2024. It wasn’t on either KEV list, because there was still no evidence of exploitation. It was added to VulnCheck KEV later, months later, and it’s still not in CISA KEV. Its CVSS score was 8.1, which is high, but not critical. It’s not a 10, and there are lots of CVEs with a 10 or a 9.2, so even this high CVSS score wouldn’t stand out in your list if you prioritized by CVSS. It was classified as an RCE according to its CVSS vectors. Its EPSS score also started very low, at 0.067, and it took months to reach a significant percentage. It’s now at 40%, which still isn’t that high.

So no automatic model, and none of the frameworks we’ve discussed, would have prioritized this vulnerability immediately. But if you opened LinkedIn or Twitter that weekend, everyone was talking about it. I call these celebrity CVEs: CVEs you probably want to remediate regardless of their scores. Whatever framework you end up using, you need a place for celebrity CVEs to go manually to the top of the list. This one was an RCE in OpenSSH, something that affects nearly every server, in a protocol right at the choke point attackers are looking at. The potential was too high to ignore, even with a CVSS score of 8.1 and a near-zero EPSS score.

How do you add asset context at scale?

Now let’s talk about adding asset context in a more scalable way than SSVC, where you have to read all that documentation and make a decision for every machine. I take a more binary approach: split all your assets into two categories, normal-risk assets and high-risk assets. How do you find the high-risk assets at scale, quickly, without choosing them one by one?

One way is to look at IP addresses. If a machine has an external IP, or you know it’s externally exposed because you have an EASM solution or your vulnerability scanner tells you it’s exposed to the internet, mark it high-risk automatically, because attackers scanning the internet can find it. Next, if you know your crown jewels, such as production servers and servers holding sensitive data, mark them too. Then there are end-of-life systems. If you have legacy systems you haven’t had time to patch, and you know they have lots of vulnerabilities, those are high-risk too, because they carry other vulnerabilities as well. And if your organization already tags assets by risk or business context, for example in an asset inventory or CMDB, integrate that too.

Why use priorities instead of severities?

One last point before we combine all of this into a practical approach: I suggest using priorities rather than severities when you prioritize vulnerabilities. Severities are low, medium, high, and critical; you know those from CVSS. Priorities are P0, P1, P2, and so on, meaning priority zero, priority one, and so on.

The first advantage of priorities is that they speak to the remediation level rather than the technical aspects of the vulnerability, which makes them easier to communicate across the organization. When you talk with the IT person who needs to fix the vulnerability, or the developer who needs to patch it, it’s easier to say, “This is a P0,” or, “This needs to be done within this SLA.” They don’t really care whether it’s a high or a medium vulnerability; that doesn’t tell them anything. They want to know how fast they need to act.

The second reason is that priority levels are more flexible. You can shape them however you want. You can make P0 the top 1% of vulnerabilities and P1 the next 5%. You can choose how many levels you want: P0 to P4, or P0 to P9 if you like. It’s harder to do that with severities, because if someone tells you a vulnerability is critical, well, it’s critical, and splitting critical into “very, very critical” and “a little less critical” is hard. With priorities, you can split the criticals into P0, P1, and P2 based on other parameters, and I’ll demonstrate that.

What does a practical vulnerability prioritization model look like?

So we’ve covered all the components you can use to build a prioritization framework that fits your organization’s needs. Now let’s demonstrate how you might do it. This is just an example. I’m not saying this is the right way to prioritize vulnerabilities; it’s a suggestion of how you can use everything we’ve discussed to build a prioritization model that works for you.

In this example, P0 has the fastest SLA: things you should remediate immediately, even on a weekend or a holiday. These are KEVs, vulnerabilities that are exploited or have a very high EPSS score, say above 90%, or celebrity CVEs like regreSSHion, on a high-risk asset, meaning an asset exposed to the internet or one of your crown jewels. P1 is the same set of vulnerabilities on every other asset. These should also be remediated quickly, just not on the weekend; maybe within a three-day SLA, or whatever works for you.

For P2 and P3, I made the same split between high-risk and other assets, but this time with all RCEs according to CVSS that also have an EPSS percentile above 80%. EPSS has both a score and a percentile, and the 80th percentile means the vulnerability is in the top 20% of EPSS scores. P4 covers all remaining RCEs, to fill the gaps where KEV and EPSS didn’t predict exploitation. And for P5, just to be thorough, I went back to CVSS scores and EPSS percentiles to filter out the noise. I’ve noted the percentage of CVEs that fall into each level, but the point is to play with the numbers and see what works for you. These numbers won’t necessarily hold for your organization, because every organization has a different tech stack.

Tips for building your own prioritization framework

A few final tips. First, use any data you have. In this example, and throughout this talk, I’ve focused on public scores that anyone can use for free. But if you pay for a threat intelligence product with more data, or use a proprietary framework like VPR from Tenable or QDS from Qualys, those are good frameworks that add more specific data. The more data you can put into your model, the better, so use whatever you have.

Second, keep fine-tuning. Start with something and see how many P0s you have. If you have too many P0s and it doesn’t make sense, you may need to change the thresholds. If no vulnerability ever reaches P0, that doesn’t make sense either, so you may need to lower the threshold. Adjust the thresholds until the model works for your organization.

Third, automate. The entire point is that everything has to be automatic. If you don’t wake up to a push notification about a P0 you need to fix immediately, it isn’t working. As I mentioned, all of these frameworks have free APIs, so anyone can build automation around them. There are lots of open-source projects that pull this data and organize it in different ways. Many vulnerability scanners incorporate CVSS, EPSS, and KEV, though not all of them. And of course, there are third-party paid products that help you build an exposure management program.

Thank you, everyone. If you have more questions about vulnerability prioritization or exposure management, feel free to reach out to me on LinkedIn. Thank you for listening.