Part 1: History of EPSS

Proactive vulnerability management is of critical importance in helping organizations identify and address security weaknesses before they can be exploited — reducing the risk of data breaches, downtime, and reputational damage. Assessing, tracking, and remediating vulnerabilities in systems is a responsibility shared by security teams, developer teams, and business owners. Vulnerabilities source from a combination of tooling and assessments like container vulnerability scanning, Static Application Security Testing (SAST), Dynamic Application Security Testing (DAST), Penetration Testing, etc. For this conversation, let’s look specifically at Common Vulnerabilities and Exposures (CVEs).

There are numerous methods for managing vulnerabilities. Some rely on more qualitative methods and system context — producing data that is descriptive and conceptual — while others take on a more quantitative approach  — producing data that can be counted, measured, and expressed using numerical values. Both methods may assign scoring to vulnerabilities to assist in risk assessment and prioritization practices.

As I’m sure many reading this have experienced, scaling qualitative practices proves quite difficult. While in-depth contextual analysis may be the most effective approach to addressing a vulnerability, system maintainers quickly encounter practical challenges with more complex systems where thousands of vulnerabilities may be present. Not every system has access to (or business justification for) the resources required to take on that workload.

Thankfully, quantitative resources have been developed and iterated on by special interest groups (SIGs) dedicated to helping the security community address these challenges. Two of these SIGs are led by the Forum of Incident Response and Security Teams (FIRST): the Common Vulnerability Scoring System (CVSS) and the Exploit Prediction Scoring System (EPSS). The first, CVSS, ought to be very familiar with security practitioners. CVSS has long been the traditional method used to score and prioritize CVEs. The second, EPSS, is relatively new (with the first release of public scores in January 2021).

The security community has produced many white papers, articles, and analyses on the effectiveness and reliability of EPSS (a few which are linked below). For the sake of this article, we’ll focus on the tactical uses of EPSS and how this can directly improve your system's security processes.

Let’s review the standard definition of risk:

Risk = Likelihood × Impact

Risk, likelihood, and impact are concepts that can be assessed using various methods, including qualitative assessments (such as expert opinions and qualitative scales) and quantitative data (such as statistical analysis and numerical measurements), to provide a comprehensive understanding of the overall risk landscape.

As expressed in the below image (Figure 1), using CVSS alone provides an incomplete picture of the risk that a given CVE represents. This is expressed explicitly by FIRST in their CVSS documentation: “CVSS is designed to measure the severity of a vulnerability and should not be used alone to assess risk.” This isn’t to say that CVSS should not be used; this is to say that CVSS provides a useful but incomplete look into the severity of a CVE (severity being a component of impact)

This brings us to EPSS.

EPSS provides part of our missing context. As stated in the EPSS documentation, EPSS scoring communicates “the probability of observing any exploitation attempts against a vulnerability in the next 30 days.” To clarify, this refers to the probability of observing any exploitation attempts against a vulnerability on some system in the wild. Used in combination with CVSS and KEV, EPSS now allows us to view the risk of a vulnerability through the lens of complementary quantitative data sources.

This analysis is simplified to address the point, however, there are nuances to take into account. EPSS relates specifically to the “Threat” component of their risk formula and does not, by itself, represent a fully comprehensive assessment of risk.

Until that fully comprehensive data-driven scoring system is created, using the data-driven systems we currently have available allows us to more effectively assess and prioritize CVEs and spend our limited security resources on the highest leverage activities.

Part 2: EPSS in practice

Let’s look at a practical example of EPSS in use with an example application.

If we look at Figure 2, a select output of CVEs from a Grype Container Vulnerability scan of the intentionally vulnerable application “Juice Shop,” two 9.8 vulnerabilities stand out that would traditionally be “highest priority critical vulnerabilities” that we’d need to focus our immediate attention on. Using EPSS, however, we can also now see that the first has a score of .01045 and the second has a score of .00083.

That’s a 1% and .08% chance of exploitation in the next 30 days.

You’ll see that there’s also a 7.4 CVSS vulnerability that also has a 1% chance of exploitation in the next 30 days. Using CVSS alone, that vulnerability wouldn’t be addressed before the 9.8 with a .08% chance. Using CVSS alone, each of the >9 CVSS vulnerabilities would be treated unequivocally as critical and a “top priority” for remediation, triggering the immediate expense of security and engineering dollars to remediate.

I do want to reiterate that these are still vulnerabilities found in the system and it is not my intention to downplay that by any means. That being said, research has shown that the vast majority of CVEs are below a 1% chance of exploitation. Using EPSS, we have access to an additional data set where we can contextualize lower CVSS-scored vulnerabilities that have a high chance of exploitation as well as higher CVSS-scored vulnerabilities that have a low chance of exploitation

How does this play out in the context of your application?

Let’s say an ISSO is tasked with a risk-based decision of a 7.4 CVSS-scored vulnerability that can’t be engineered around without significant effort from the engineering teams. The 7.4 CVSS score by itself might (correctly) indicate caution in accepting this risk. This ISSO, however, uses EPSS in addition to CVSS and sees there is a 1% chance that the vulnerability may be exploited in the next 30 days. This analysis gives the ISSO confidence to accept the risk and document their rationale as part of the risk-based decision.

Another ISSO for a large system recently received a vulnerability report with 3,000 CVEs and is up against an assessment deadline to triage and remediate these findings. They only have enough time to remediate the most critical vulnerabilities. Instead of solely using CVSS and wading through contextual analysis of hundreds of critically CVSS-scored vulnerabilities, the ISSO runs a script to update the report with EPSS in addition to CVSS. The ISSO sees that 95% of the 3,000 vulnerabilities have an EPSS score below .01 (1% chance of exploitation). The remaining 150 vulnerabilities above .01 EPSS are a diverse assortment of low, medium, high, and critical CVSS-scored vulnerabilities (an analysis that would not get done in time going through each CVE line by line). The application team is able to remediate each of these top 150 vulnerabilities and contextualize the remaining ones in the backlog for remediation after their assessment.

Now, what if the EPSS score changes?

EPSS regularly updates and tunes its scoring methodology as new information comes out. With regular scanning, an ISSO can view what vulnerabilities are above a threshold that they deem too high of a risk (1%, 5%, 25%, etc.) and prioritize those for remediation using CVSS as supplemental information. If there’s a 4.3 CVSS vulnerability that now has an 87% chance of exploitation, shouldn’t that be prioritized above the 9.8 with .08%? These are questions the ISSO is now better equipped to address with data informing their decision process.

Conclusion

EPSS (in the same camp as CVSS) unfortunately doesn’t apply to all risks that can be found within a system, but for the vulnerabilities it does apply to, it provides a great deal more context to properly inform risk-based decisions and prioritize vulnerabilities that pose a risk to our systems. By focusing on the vulnerabilities that present the highest risks to our system, we cut down inefficiencies and improve system security posture while optimizing the cost of security and development hours.

About the author: Lloyd Evans an ISSO and is the Director of Governance, Risk, and Compliance at Aquia and an Air Force Veteran with experience in the federal ecosystem spanning the Air Force, U.S. Navy, and the United States Department of Health and Human Services (HHS).