Practical Guide to the EPSS Score

In 2024, approximately 40,000 new vulnerabilities were reported, marking a 38% increase from the previous year. This rise highlights the complexity of vulnerability management for organizations trying to understand what truly impacts their risk. Many of these vulnerabilities were classified as critical, making it challenging for organizations to prioritize their efforts effectively. 

So, how can they filter out the critical information from the less relevant data? Risk-based vulnerability management requires the combination of asset visibility mapped to exploitability instead of the standard approach of tackling the highest severity vulnerabilities first. This paradigm shift moves organizations from a theoretical to a data-driven approach specific to the business environment, allowing organizations to focus limited resources on what matters most. 

Up until now, determining exploitability required deep diving into each of the vulnerabilities identified. That changed when Exploit Prediction Scoring System (EPSS) was introduced. The rest of this article explores EPSS, including how it works, how to implement it, and how to use EPSS to communicate risk. 

Summary of key EPSS concepts 

Defining EPSS mechanics

The EPSS project is developed and maintained by Forum of Incident Response and Security Teams (FIRST), and its most recent version was released in March of 2025. Unlike CVSS, EPSS takes several public and private data points to measure exploitation probability over the coming 30-day window.

EPSS employs XGBoost, a machine learning algorithm, to analyze patterns from multiple, up-to-date data sources and build the overall score. The model uses vulnerability characteristics as well as actual exploitation and incorporates

• Vulnerability details, such as the affected products
• Vulnerability types, and 
• The access necessary for successful vulnerability exploitation. 

Dark web and exploit repositories are also monitored for chatter, and telemetry is gathered from security sensors across networks related to active exploits.

Overview of EPSS inputs (source)

The world’s most sophisticated asset discovery and dependency mapping for vulnerability management

Learn More

Discover assets automatically including hardware, software, and cloud infrastructure

Match the assets against your software and hardware license agreements

Comply with your service license needs comprehensively and confidently

EPSS tracking tools

Fortunately, tools are available to assist with this process. Many modern security scanning tools, such as Tenable.io, Nessus, and Open Web Application Security Project (OWASP) Dependency Track, include EPSS scores in their reports. A dashboard displays the scanned assets and associated CVSS and EPSS scores.

If there is integration between asset management and scanning tools, you can map the findings directly to identified critical assets. Additionally, a SIEM (security information and event management) or SOAR (security orchestration, automation, and response) tool can ingest EPSS data and information from your asset management tools, providing a comprehensive view of your vulnerability landscape.

Understand what’s in your environment

Systems are complex, often consisting of hundreds or thousands of individual assets, which makes vulnerability management difficult. However, implementing asset management is a table stake in cybersecurity. An organization with a well-defined asset map can ensure it keeps running smoothly.

Knowing what you have and the impacts of those assets on business operations are two different things. A vulnerability in PostgreSQL may be concerning when it is announced, but depending on what version is running, it may not be critical. Similarly, the data stored in the PostgreSQL instances may not be essential to the business’s operation. These and other factors play into how an organization reacts to a vulnerability. 

CMDB Discovery

Organizations discover and identify assets primarily through CMDB discovery. CMDB Discovery maps applications and business processes to the hardware and software components that make them work, often divided into categories of configuration items (CIs). In a perfect world, an organization would be able to look at its list of CI items, displayed on a dashboard, and be secure in the knowledge that it has identified and categorized its entire compute infrastructure.

An example of a dashboard showing an organizations CI items (source)

However, most organizations find this isn’t the case. There is a constant churn of devices on their networks, which may or may not be managed and controlled effectively. The challenge is exacerbated by the fact that basic discovery techniques don’t support legacy hardware and software components like Unix servers from vendors like Sun Solaris or IBM. Organizations use tools such as Device42 to passively and actively discover all assets on their network to mitigate this risk and ensure that their CMDB is as accurate as possible.  

Dependency mapping

A second method for identifying assets and their interconnections is dependency mapping. This is especially helpful when looking at a vulnerability and determining the potential blast radius. For instance, consider a vulnerable Docker image from a 3rd party that allows for remote code execution. Dependency mapping helps identify where the image is deployed and where the other components or systems that may be impacted are. Additionally, this mapping highlights the downstream systems that the container compromise could indirectly impact. 

For example, the container could host a microservice used in payment processing. This service interacts with a customer database, communicates with an external API, and is hosted on a Kubernetes cluster. This means that while remote code execution (RCE) impacts the 3rd party image in the container, the risk to the customer database is high. Legal, contractual, and regulatory impacts could raise the risk even higher, depending on the data in that database.

Dependence mapping example (source)

Most importantly, a well-established configuration management process and tooling allow the organization to map its security controls to its assets. Suppose the organization identifies a vulnerability in its SQL Server software that does not include an immediate patch. In that case, it can review its compensating controls, such as access restrictions and monitoring, to provide some cover while it awaits a patch.

Practically implementing EPSS

Knowing which assets are considered critical to the organization will help position remediation efforts when a new vulnerability is discovered. Take the example from before of a vulnerability found in a 3rd party image running in a container that processes customer payments. Considering the dependency map that identifies the various touch points means that you can determine the potential impact. Even if the CVSS and EPSS scores are low, given the criticality of the workflow, the organization may opt to move forward with a remediation to limit the risk.

In an ideal vulnerability management program, the organization first receives notification that a vulnerability has been found, whether through scanning, penetration testing, audit, or external notification. It overlays findings with asset management to identify the impacted systems. It reviews the most critical system based on the CVSS and EPSS scores, and develops a priority plan to mitigate or remediate the vulnerability. The organization’s goal is to first apply pressure to the most critical areas to prioritize team efforts.

To operationalize this information, you’ll need to define internal thresholds that align with your risk tolerance of the organization. Start with setting EPSS scoring categories as exemplified below:

• High Likelihood (0.7-1.0): Requiring immediate attention as these are likely to be exploited in the short term.
• Medium Likelihood (0.4-0.69): Monitor closely for potential increase in rating, and plan for remediation based on the context of the risk.
• Low Likelihood (0.0-0.39): Prioritize remediation of potentially critical assets or defer remediation if security controls are sufficient to limit the risk.

This categorization works well on its own but requires additional details to be effective. You should combine the categorization with the asset management and dependency mapping details. For example, a High EPSS coupled with core infrastructure should result in a critical overall rating. At the same time, a Medium EPSS with a non-sensitive system should be treated less critically and have future scheduled remediation.

Pairing the CVSS score as the severity of impact and EPSS as the likelihood of exploitation provides a better picture of the overall risk. For example, a High CVSS and EPSS would require immediate attention, whereas a High CVSS but low EPSS could require monitoring and compensating controls. Other data points should be considered, such as the sensitivity of the data, whether the system is externally facing, and whether there are regulatory impacts to the system being breached.

One attribute of an EPSS score is that it can change over time. Threat intelligence may determine increased activity on exploit sites around the specific vulnerability. This activity will raise the EPSS score overnight and become a challenge to keep up with. Organizations can leverage their existing tools and processes to monitor for changes through existing vulnerability management or scanning tools. Additionally, scripts can be created to pull scores daily or weekly, with trend analysis used to monitor changes in exploitability. 

If an identified vulnerability’s EPSS score has risen due to new exploit information, the organization needs to feed that back into its overall vulnerability management program. This includes updating the reporting metrics to include EPSS score as one tracked data point. The remediation workflows must be flexible enough to react quickly to a change in EPSS score.

High-level EPSS implementation example (source)

Just as an organization constantly assesses its security posture, the efficiency of the vulnerability management program needs to be evaluated as reality changes. This requires building a program that is agile enough to respond to changes in EPSS and helps inform how security controls, processes, and architecture are built. For example, the architecture should be flexible enough for rapid access policy adjustments in networks and cloud resources. You could even go as far as automating EPSS, then automating a response to an increase in EPSS. For instance, you could automatically restrict workload or network segments if an EPSS score rises above a certain threshold. 

EPSS scoring can also be integrated into the software development process and CI/CD (continuous integration/continuous deployment) pipelines. In this instance, a software build may be blocked if a vulnerability scan uncovers a vulnerability with an EPSS score of High or some other set of markers determined by the organization. This doesn’t just stop the release of a potentially exploitable vulnerability; it also educates developers on EPSS scores and their role in reducing the release of exploitable code.

While EPSS scores can provide valuable context for vulnerabilities, it’s essential to consider some limitations and constraints. For one, it cannot predict zero-day vulnerabilities as there will not be any publicly available information, a key requirement for EPSS. It also relies heavily on historical and heuristic information to be effective. Attackers often find novel ways to take advantage of system weaknesses, which may not always be reflected in the EPSS score. 

With the benefits and limitations in mind, EPSS scoring can go beyond the technical aspects of finding, classifying, and resolving vulnerabilities. It can also prioritize risk in conversations with your business partners. 

Communicating risk with EPSS

The EPSS score should be used to provide actionable insights to business leaders and simplify often complex and disjointed security metrics. With EPSS, security leaders and teams can:

• Focus on the likelihood of a vulnerability being exploited rather than on the simplified CVSS score or other nebulous metrics.
• Using the dependency mapping and understanding of the critical assets in the organization, security leaders can put vulnerabilities into the context of the business risk by highlighting vulnerabilities that pose immediate threats to critical assets.
• Focus on the vulnerabilities that can become risks with a likely business impact.

Using EPSS combined with other factors like CVSS, vulnerabilities can be ranked and presented in a dashboard that reflects the risk while making it easier for non-technical decision makers to understand. A sample dashboard may look like this.

Using this information, business leaders can work with security to prioritize resources and funding for critical business areas. However, EPSS also allows security leaders to clearly articulate why specific actions must be taken to protect the business. 

Closing vulnerability gaps with EPSS

In many cases, organizations utilize CVSS scores to determine the criticality of a vulnerability. But this only tells part of the story. CVSS scores are generic scores that can be broadly applied to many environments. Additionally, it is missing one key ingredient: how likely is this vulnerability to be exploited? 

This is where EPSS comes in. It uses public and private information to create a score between 0 and 1 (think 0-100%) based on metrics like:

• CVSS score
• Vulnerability age
• Availability of exploit code
• References in security advisories.

 It then applies machine learning to identify patterns in the gathered metrics to predict the likelihood of an exploitation. While not perfect, it provides an additional datapoint that you can use to give context on what vulnerabilities an organization should tackle. 

For example, consider a vulnerability in OpenStack. The CVE (common vulnerabilities and exposures), when assigned, could be set with a CVSS score of 9.8 (Critical). EPSS identifies already available exploits and acknowledges that it’s been 5 days since the vulnerability was disclosed, with increased communication on hacker channels. Based on these factors, the EPSS score was assigned 0.85, indicating a high likelihood of exploitation requiring the security team to act fast to patch.

The learning model is not updated daily; however, the data is continuously updated as new input becomes available. This differs from CVSS (common vulnerability scoring system) scores, which change infrequently, if at all, once established. EPSS scores can shift almost overnight, which can be both beneficial and problematic. 

For example, a vulnerability that initially has a low EPSS score may suddenly become critical if exploit code is created and begins to circulate, leading to a potential urgency in addressing the issue.

Comparative overview of EPSS vs CVSS (source)

Alternatively, a low CVSS score with a high EPSS score could still be dangerous and require attention. This shows how exploitability provides an additional layer that helps organizations prioritize their efforts. 

Organizations with less mature vulnerability management programs are likely to focus on simply tackling the vulnerabilities with high and critical CVSS scores, regardless of their ability to pose any risk to the organization. This leads to wasted effort and time spent chasing vulnerabilities with little impact.

All this sounds great, but identifying vulnerabilities is the easy part. Knowing how the vulnerability impacts your environment is the intention of any good vulnerability management program.

Last thoughts

Vulnerabilities are an inherent part of technology. While various tools are available to help understand the overall impact on an organization’s risk, the EPSS score is valuable to your toolkit. It provides a risk-based security perspective that emphasizes the actual exploitability of a vulnerability. When combined with asset management, dependency mapping, and scoring systems like CVSS, organizations can enhance their security posture while efficiently utilizing resources.

Mature vulnerability management programs can integrate all these data points to make informed decisions that facilitate clear communication between security teams and the business. Effective vulnerability management is not about addressing every possible weakness; instead, it’s about concentrating the organization’s efforts on vulnerabilities that impact business value.