TL;DR
- CVSS measures severity and impact, rather than real-world risk. Its metrics can be complex to interpret and are explicitly not intended to be used for vulnerability prioritization.
- EPSS measures the probability that a vulnerability will be successfully exploited in the next 30 days. In any 30-day window, only about 2.5 to 3% of published CVEs show exploitation activity. It uses machine learning with inputs from CVSS and online activity, but it relies on historical data and lacks context. It predicts whether a vulnerability is likely to be exploited, not whether it has.
- CISA KEV lists CVEs with reliable evidence of active exploitation and a clear remediation action, and covers roughly 0.5% of published CVEs. This is useful for prioritization as it lets you focus on vulnerabilities that are active and that you can fix, but its limited scope means it is not comprehensive.
- Reachability analysis determines whether a verifiable execution path exists between an untrusted input and a vulnerable function or dependency inside your application. Combining it with CVSS, EPSS, and KEV is what makes vulnerability prioritization reflect real risk.
Why Do You Need to Perform Your Own Vulnerability Prioritization?
Vulnerability prioritization must be accurate and relevant to your unique environment, from the development tools you rely on, to the AI enhancements that enable modern development, and the software dependencies that provide functionality and reduce workloads.
While global threat scores are a useful indicator of exploitability, they cannot be relied on to assess true impact and risk. Your development, testing, and production environments have their own contexts, and a critical vulnerability that is unreachable in your environment could divert valuable AppSec resources from actual threats.
This guide explains why vulnerability prioritization that reflects reachability analysis in your operating environment is critical, why prioritization based only on CVSS scores is flawed, and how to combine public metrics with your own context to create actionable prioritization workflows.
Why CVSS-only Prioritization Fails
CVSS (Common Vulnerability Scoring System) is the standard framework for measuring the severity and impact of a vulnerability if it were to be successfully exploited.
CVSS measures base metrics, including the access vector and complexity, whether authentication or re-authentication is required for the exploit to succeed, as well as impact metrics, including the effect on the confidentiality, integrity, and availability of affected data and systems. It also measures exploitability, remediation level, and report confidence; metrics that will change over time as vulnerabilities are investigated and fixed.
The CVSS metrics are then used to create a score from 0-10 for each vulnerability, which is then assigned a severity rating:
| CVSS Score Range | Severity Rating |
| 0.0 | None |
| 0.1 to 3.9 | Low |
| 4.0 to 6.9 | Medium |
| 7.0 to 8.9 | High |
| 9.0 to 10.0 | Critical |
FIRST states that CVSS base scores are designed to measure the severity of a vulnerability and should not be used alone to assess risk. They are supposed to act as an indicator, with the metrics behind them as an information source that informs vulnerability prioritization.
CVSS metrics are detailed and can be difficult to understand. However, the primary reason that CVSS fails as the sole metric for vulnerability prioritization is that it does not reflect real-world risk. This is why prioritization requires knowing whether a vulnerability is exploitable or not. For example, if a vulnerable function in a dependency in your software supply chain is never called, it poses no immediate risk.
Failure to recognize the actual exploitability and impact of a vulnerability in your environment results in the wrong vulnerabilities being fixed first, delaying remediation of actual threats. Improper prioritization also increases the risk of alert fatigue, which can cause remediation to be delayed or overlooked.
FIRST reports that in any 30-day window only about 2.5 to 3% of published Common Vulnerabilities and Exposures (CVEs) show exploitation activity, and that high CVSS severity scores are only slightly better than random at predicting exploitation. This is what led to the creation of the EPSS (Exploit Prediction Scoring System).
EPSS: The Probability That a Vulnerability Will Be Exploited
The EPSS builds on CVSS data and attempts to predict whether a vulnerability is likely to be exploited in the next 30 days. This is measured as a probability value from 0 to 1.
EPSS scores are calculated using a complex machine-learning algorithm that consumes real-world threat intelligence collected online, from hacking tools to conversations, actual incidents, and other activity, including CVSS metrics. Interestingly, there is no correlation between CVSS and EPSS scores.
Alone, EPSS is still not enough for vulnerability prioritization (though it is much better than CVSS): while it is a much more accurate assessment of real exploitability, it relies on historical data and is still unaware of your environment. It also only predicts whether a vulnerability is likely to be exploited, not whether it has. This is where the Cybersecurity and Infrastructure Security Agency (CISA) Known Exploited Vulnerabilities Catalog (KEV) is applicable.
CISA KEV Catalog: Confirmed Exploitation In the Wild
The CISA KEV catalog documents known vulnerabilities with a CVE identifier for which there is reliable evidence of active exploitation in the wild, and a clear remediation action such as a vendor-provided update. This means it covers roughly 0.5% of published CVEs. While this is a limited scope, the CISA KEV catalog provides actionable information on immediate threats. Vulnerabilities with known exploit paths are a much greater risk, and this affects prioritization.
However, the KEV catalog is reactive: it’s based on known incidents, and there may be a delay between discovery and a fix being formulated before the vulnerability is added to the catalog. OX Security’s analysis of 10 common KEV CVEs across more than 200 cloud environments found that none posed actual risk to the containerized workloads they ran in, which is why KEV alone is not a suitable input for prioritization; OX calls this the KEV Illusion.
What Is Reachability Analysis in Application Security?
Reachability analysis determines whether a verifiable execution path exists between an untrusted input (the source) and a vulnerable function or dependency (the sink) inside an application.
Tools to measure exploitability of CVEs, even those that factor in CVSS, EPSS, and KEV data, are still missing vital context about your software development lifecycle (SDLC). These scores evaluate severity, exploitability, and actual activity in other environments, providing a valuable indicator of risk. Your environments are, however, unique and have unique weaknesses and controls that must be factored into the security of your SDLC.
As a result, you need to take all available authoritative data about a vulnerability and apply it to your own systems and software supply chain. You can then check if there are viable exploit paths and prioritize reachable, imminent threats over inert ones. Like other vulnerability prioritization metrics, reachability does not stand (and cannot exist) alone, as it is informed by other data sources.
Combining CVSS, EPSS, CISA KEV, and Actual Environmental Reachability Context Into a Working Framework
You need to know about a vulnerability before it can be mitigated or remediated. CVSS, EPSS, and CISA KEV are all inputs that you then combine with your context to assess the real-world reachability of a vulnerability in your SDLC. This helps ensure coverage of all assets and known vulnerabilities, without creating fatigue and noise that leads to backlogs.
The post-CVE-era prioritization stack should resemble the following framework, and cover all development toolchains, testing environments, and deployment images, containers, and infrastructure:
| Severity (CVSS) | Probability (EPSS) | Confirmation (KEV) | Your Context |
| Awareness of a vulnerability. This can be used to create a register of vulnerabilities that exist in your SDLC. | Predicted threat of a vulnerability. Acts as an initial indicator of the risk a vulnerability poses, allowing for further prioritization. | Confirmed exploited vulnerabilities with an immediate fix can be made high priority to remove them as a threat, allowing your team to focus on other high probability threats. | Context that accurately confirms reachability of a vulnerability should supplement other inputs to prioritize real threats that require manual remediation and confirmation. |
Linking these key data sources into an effective vulnerability prioritization process requires the right tooling. When choosing an enterprise vulnerability prioritization and management tool, you should choose one that reduces noise and streamlines workflows, without introducing gaps.
Detecting and Prioritizing Vulnerabilities at Scale in AI Development Workflows
AI-driven software development has fast become the standard workflow. Developers can write code faster, and AI can generate boilerplate and even entire working projects from plain-language prompts. Whether it’s leaning on AI-generated suggestions or total vibe-coding, even the most AI-apprehensive developers will eventually skip a review or allow agents to act or generated code to run without proper guardrails.
Studies have shown that this is a tangible risk. Georgia Tech’s Vibe Security Radar confirmed 74 vulnerabilities traced to AI-generated code, 14 of them critical and 25 high, with 56 found in the first three months of 2026 against 18 in the second half of 2025. A Stanford study showed that developers thought that they were writing more secure code than if they hadn’t used AI.
An SDLC security strategy that worked up until a few years ago is ineffective in this new environment. The volume of code generated, and the risks it introduces such as insecure code, slopsquatting, prompt injection, and other novel AI-assisted development risks, make it practically impossible for any security team to maintain coverage.
Even developers who still rely on largely traditional workflows are not safe: modern software development involves thousands of dependencies. Software is no longer developed from scratch, and to be competitive you must “stand on the shoulders of giants” and leverage dependencies for authentication, storage, and other critical functionality rather than writing, testing, and maintaining it yourself. These packages and their own dependencies can introduce AI-generated code and vulnerabilities.
These emerging vulnerability prioritization challenges are multiplied with each added development tool, CI/CD pipeline, and deployment image and container. Vulnerabilities can persist in these environments if security tools do not gain and maintain context that spans all of them.
OX Code, the code and supply chain pillar of the OX platform, maps every finding to CVSS, EPSS and CISA KEV and then applies reachability, exploitability, and damage factors from your own environment. The OX Platform performs full graph-based reachability analysis that correlates data from code appearance to deployment, covering your full SDLC. It identifies what vulnerabilities are reachable with real attack paths, what you should fix first, and helps your team prioritize vulnerabilities while reducing noise and the need for manual triage. See how OX prioritizes with evidence.
FAQs
CVSS (Common Vulnerability Scoring System) is the standard for measuring the severity of a vulnerability in a computer system. EPSS (Exploit Prediction Scoring System) complements CVSS as the standard for measuring the exploitability of a vulnerability, assessing the probability it will be exploited in the next 30 days. CVSS measures the impact of a successfully exploited vulnerability; EPSS measures the likelihood of the exploitation occurring.
Vulnerability prioritization is dependent on your unique development, testing, and production environments. You should establish a documented vulnerability management process that starts with CVSS, EPSS, and CISA metrics, and that factors the reachability of affected assets, and the criticality of a vulnerability in your environment. This is impractical to do manually at any scale, and should be enabled by an appropriate vulnerability management platform.
The Cybersecurity and Infrastructure Security Agency (CISA) Known Exploited Vulnerabilities Catalog (KEV) is the US government’s authoritative source of vulnerabilities that are known to have been successfully exploited. It is a valuable input for your vulnerability management and prioritization. It does not override CVSS, but complements it with additional data on only actively exploited vulnerabilities.
Static and dynamic code analysis can be used to understand the reachability of a vulnerability in your codebase or dependencies. Factors such as whether the target system is internet-reachable, and whether an affected function or library is actually called by your code, or whether other controls prevent its exploitation, can also be considered.
A vulnerability management platform is critical for the successful prioritization of vulnerabilities in your software supply chain. Performing vulnerability prioritization manually at scale, across systems, applications, codebases, and potentially thousands of dependencies, is practically impossible. A security platform that includes vulnerability management is necessary to identify and prioritize vulnerabilities by factoring in CVE, EPSS, and KEV data, combined with local context.
