Exploit Prediction Scoring System (EPSS) and Risk-Based Vulnerability Prioritization
The overwhelming volume of software vulnerabilities and the intensifying threat landscape underscore the critical importance of effective prioritization. Increasingly, this means looking beyond the technical severity of vulnerabilities to assess the likelihood of an attack. The Exploit Prediction Scoring System (EPSS) advances vulnerability assessment and prioritization by quantifying the likelihood a vulnerability will be exploited. In this post, we delve into the core aspects of EPSS and its role - and limitations - in achieving risk-based vulnerability management.
What is EPSS versus CVSS?
EPSS delivers exploit predictability - a key variable in risk-based vulnerability prioritization - by collecting vulnerability data to assess the likelihood of an exploit over the next 30 days. According to the Forum of Incident Response and Security Teams (FIRST) which manages EPSS, “The Exploit Prediction Scoring System (EPSS) is a data-driven effort for estimating the likelihood (probability) that a software vulnerability will be exploited in the wild.”
EPSS is different from and complementary to severity scoring systems like the Common Vulnerability Scoring System (CVSS). Where CVSS measures the ease and impact of an exploit based on metrics like attack vector, complexity, environmental variables, data confidentiality, etc., EPSS is focused on predicting the likelihood of an attack.
EPSS and CVSS together provide security teams with valuable data and insights to prioritize. Faced with an overwhelming volume of vulnerabilities, organizations need to understand the severity of vulnerabilities, the likelihood of an attack, and the impact based on the affected asset for effective risk-based vulnerability management. When a new CVE is published, EPSS supplements CVSS severity scoring with real-world context to predict if a vulnerability is more or less likely to be exploited in the next 30 days.
How does EPSS work?
EPSS calculates the exploit probability of vulnerabilities by leveraging a machine-learning model that identifies patterns between vulnerability data and exploit information to produce a probability score between 0 and 1 (0-100%). FIRST trains the model by taking 14 months of historical data - 12 for training and 2 for assessing the model’s performance (i.e. its ability to predict the exploit landscape in those 2 months) and iterates to improve predictions. Critically, EPSS updates daily to actively predict exploit probability as the threat landscape evolves.
EPSS calculations are different from severity scores. A vulnerability with a low severity or CVSS score but actively exploited (or with data to predict exploits will be high) would have a high EPSS score. Conversely, a high-severity vulnerability with little exploit activity would have a low EPSS score. While there is some correlation between CVSS and EPSS score, EPSS data refutes the assumption attackers only target high-severity vulnerabilities.
When applying EPSS in practice, it is important to understand the strengths and limitations of the scoring system for practical risk-based prioritization.
Why EPSS is important
Organizations have limited capacity to remediate vulnerabilities and face far greater quantities of vulnerabilities than they can address immediately. This makes it critical to optimize remediation efforts to minimize exposure and risk. Prioritizing just on severity is not the most efficient when it causes teams to spend time fixing vulnerabilities with low exploit probability while more immediate threats are left unaddressed.
EPSS and CVSS 4.0 mark important progressions broadening the scope of vulnerability scoring and assessment beyond severity. EPSS addresses historical concerns by going beyond base severity scores to consider threat intelligence data to predict and quantify the real-world likelihood of an attack. This enables a more nuanced approach to vulnerability prioritization. Critically, it also provides a standard organizations and testing vendors can apply across tools and testing sources to prioritize CVEs in their software portfolios and infrastructure.
What are the limitations of EPSS?
Beyond the inherent limitations of predicting the future, EPSS falls short of providing a complete risk assessment. There are three notable limitations of EPSS:
- The scope of EPSS does not include severity or environmental factors. EPSS is limited to exploit prediction. While it can and should be used in conjunction with CVSS, it does not natively account for severity and environmental factors.
- EPSS is limited to known CVEs. It does not provide an exploit prediction score for software weaknesses and vulnerabilities without a CVE.
- EPSS does not consider the business context necessary for evaluating the impact of an exploited vulnerability for risk-based vulnerability management.
These limitations emphasize the need to complement EPSS data with severity calculations, threat intelligence, and context mapping to calculate business risk and optimize remediation efforts.
Leveraging EPSS in ArmorCode
Organizations should leverage EPSS as one of three key variables for vulnerability assessment and prioritization:
- The severity of the vulnerability (CVSS)
- The likelihood of an attack (EPSS)
- The business impact of an exploit
EPSS improves vulnerability assessment from a one-dimensional severity score to a two-dimensional severity and probability scale. ArmorCode helps organizations further improve risk-based prioritization by aggregating findings and relevant CVSS and EPSS data in a single platform and mapping findings to business context to measure impact. This provides a full three-dimensional view of risk. In addition to leveraging EPSS and CVSS data to better assess the technical severity of CVEs, ArmorCode also calculates the risk of findings without a CVE (for example, CWE code weaknesses and findings from penetration tests and bug bounties) as part of a complete risk score calculation.
Most importantly, ArmorCode makes this data actionable to quickly prioritize security findings, automate workflows, define and manage risk-based Service Level Agreements (SLAs), and measure and manage risk at any hierarchical level from individuals and teams to products and sub-products or business units and organizations.