blog

How can you mix CISA KEV and EPSS? A detailed analysis of the exploitability score

CISA KEV analysis EPSS and CVSS

CISA KEV and EPSS have been debated and discussed as tools to enrich vulnerability data and help organizations decide what to fix. Both Data sources have helped analyse which vulnerability to address first. Any organization performing application security and infrastructure vulnerability management should consider using them. Since BOD 22-01, federal agencies must fix vulnerabilities within a specified timeframe. With this research, we cross-reference those two tools to see what trending and story we can extract from the data.

Note: The post has an embedded script and iframe to interact with the data directly. Make sure you have those enabled (on mobile, one of the visuals will ask to download a file, ignore this)

What is CISA KEV

The CISA, or Cybersecurity & Infrastructure Security Agency, is a federal agency of the United States government responsible for ensuring the security of the nation’s critical infrastructure. The Known Exploited Vulnerabilities (KEV) list typically lists known software vulnerabilities that are actively or recently exploited.

These vulnerabilities are typically discovered in popular software or systems, and the details are provided so that IT professionals and systems administrators can take the necessary steps to patch or mitigate them. The objective of this is to inform the public about existing vulnerabilities in order to prevent cyberattacks.

All federal civilian executive branch (FCEB) agencies must remediate vulnerabilities in the KEV catalogue within prescribed timeframes under Binding Operational Directive (BOD) 22-01, Reducing the Significant Risk of Known Exploited Vulnerabilities.  

The following sections detail the criteria behind each of the three thresholds for KEV catalog updates, which are:

  • The vulnerability has an assigned Common Vulnerabilities and Exposures (CVE) ID.
  • There is reliable evidence that the vulnerability has been actively exploited in the wild.
  • There is a clear remediation action for the vulnerability, such as a vendor-provided update.

What is EPSS?

The Exploit Prediction Scoring System (EPSS) is an open, data-driven effort for estimating the likelihood (probability) that a software vulnerability will be exploited in the wild. Our goal is to assist network defenders in prioritizing vulnerability remediation efforts better. While other industry standards have been useful for capturing innate characteristics of a vulnerability and providing measures of severity, they are limited in their ability to assess threats. EPSS fills that gap because it uses current threat information from CVE and real-world exploit data. The EPSS model produces a probability score between 0 and 1 (0 and 100%). The higher the score, the greater the probability that a vulnerability will be exploited.

CISA KEV and EPSS who is the most exploitable product and vendor

The first analysis was to cross reference EPSS and CISA KEV with the size of each element describing the count of how many vulnerabilities (regardless of the severity)

  • Size = Number of exposures captured in cisa kev
  • Shade (from light to dark) = EPSS scoring (from light to dark)
  • Data includes all the results from the entire of the CISA KEV catalogue

DATASET: 

CISA Kev’s recent data (fetched mid-May 2023) shows around 1000 vulnerabilities across several products and vendors. 

We cross-referenced the vulnerability data with EPSS data to explore which Vendor and product is most vulnerable.

CISA KEV, Vendor, Explioitablitiy

DATASET: 

In the dataset, each square has

  • Vendor
  • Number of Vulnerabilities for the Vendors in CISA KEV
  • CVSS Vulnerabilities
  • Magnitude (sum) of all the EPSS Data (colour)
  • Count of CVE (size of the blocks)
  • Text: Vendor, Product, EPSS (95 percentile), Number of Vulnerabilities per product

What are the vulnerable products in CISA KEV?

In this analysis, we take a cutoff point at 0.8; despite this creating a binning element, it can display which vulnerabilities are considered highly exploitable and which are not. Highly exploitable vulnerabilities tends to be on the range of 0.7 and above, even tough this is an arbitrary judgment that might disappear in the future with more data and exploits. In general, the closer to 1 the EPSS value is the higher is the probability of exploitation.

Percentage of Highly exploitable vulnerabilities CISA KEV, Exploitability, EPSS

Note: for this research, we choose to bin the vulnerability in highly exploitable or low exploitability at 0.8 or higher (fairly high value). Data has shown that above 0.7 the EPSS values become highly exploitable. Nonetheless, this should not be the only value of judgment as explained below. EPSS shall be used as an indicator of exploitability together with other factors like location, business criticality, other CTI like CISA KEV and so on.

Credit EPSS

Amongst the full list of vulnerable infrastructure, software and application, the number of high exploitable vulnerabilities (EPSS> 0.6) in CISA KEV only 42% are highly exploited in the wild, according to EPSS data cross references with CISA KEV. The colour scale indicates a deeper colour for the vendor with a higher EPSS score. 

Top 10 Vulnerable products

The data and value were taken by:

Vendor NameNumber of VulnHigh Exploitable vulnerabilitiesLow Exploitable vulnerabilitiesCritical CVEHigh CVEMedium CVE
Microsoft259116143831109
Adobe6038224807
Apache282538016
Oracle3122911012
Cisco62134921328
VMware37122516012
Google4710372029
SAP3110211507
Netgear12102902
Atlassian990303
Zoho990204
D-Link1486805
Apple6675920025
Fortinet317241106
Crestron225171105
WSO2225171105
GIGABYTE225171105
SugarCRM225171105
Citrix1147303
CISA KEv Product, EPSS, High exploit, Application Security

When looking at the various products, Microsoft Windows and Cisco Products score the highest as they have the highest density of product lines and number of lines of code per product. 

Over the years, this data seems to be pretty consistent and shows a high level of exploitability and several vulnerable products the years. 

Over 2023 (we are currently in may), we have a limited amount o dataset available.

The number of highly exploitable products compared to the product with the highest number of vulnerabilities (sum critical high, medium and low) remains coherent with the rest of the data and confirms that the vendors with the highest amount of product lines/number of code lines remain the most frequent. 

Products and line of codes

One of the fallacies of the analysis is the number of lines of code/product lines; White we don’t have the number of codes per product we can assume the number of vulnerable products.

The study still has Microsoft on top, followed by Adobe; Apple has mostly two product lines, even though many individual software (reserved for future analysis) has been bumped down in places.

The picture above shows the products with the highest CVSS factor cross-referencing the EPSS score.

All factors should be considered when prioritizing vulnerabilities 

Each factor mentioned in this research should be considered when prioritizing infrastructure and application security vulnerabilities. Considering only one factor might lead you on the wrong path.

Highly exploitable Products, CISA KEV, EPSS, CISA, Number of high exploitable Value in CISA KEV

One factor, like CVSS can help prioritise what’s more critical, but from existing research, we know that only a few elements in CISA KEV are highly exploitable. CVSS as the base value can be used as a starting point for vulnerability prioritisation with CISA kev and deciding which exploit is more dangerous. 

EPSS factor can help to inform with EPSS KEV which vulnerability is more likely to get exploited

Highly exploitable Products, CISA KEV, EPSS, CISA, Application Security, Infrastructure security vulnerabilities
Number of high exploitable vulnerabilities in CISA KEV

When deciding what to prioritize in patching, all the data points should be used.  As shown below, selecting the highest exploitable from the EPSS score might miss some classes of vendors like Apple, which could lead into considering those vulnerabilities are not exploited in the wild or impactful. Because of the extensive attack surface, Apple vulnerabilities might be highly impacting, especially if VIP are using. 

The data also confirms that Apache status, Atlassian products, libraries, and dev tools are exploited in the wild and at scale. 

Apple, CVSS, EPSS, Exploitable, Vulnerabilities

Conclusion: Risk-based Approach

Highly exploitable Products, CISA KEV, EPSS, CISA, Application Security, Infrastructure security vulnerabilities

The data shows that the vendors with the most products remain more exposed to the most exploitable vulnerabilities. Windows, by far, with a code base of 50 million lines of code, remains the most vulnerable product overall. 

The dataset is useful for traditional infrastructure and patching, but the application security vulnerabilities are still scarce in the CISA KEV set. 

A risk-based approach to vulnerabilities helps include all the considered elements, like CISA KEV, EPSS, impact on assets, and visibility, into one unified approach. In conclusion, not all critical vulnerabilities are equal.

A critical vulnerability on a product that is externally facing impacts on top-line revenue-generating applications, products, and server is more important than a critical vulnerability on a system that is not revenue-generating and not business-critical. 

With a mature risk-based approach to application security vulnerability management, the security team can be ensured that:

  • Business criticality is taken into consideration when resolving vulnerabilities
  • The probability of exploitation is taken into consideration when resolving and reporting vulnerabilities. The probability o exploitation can be derived by several factors:
    • Type of vulnerability (software, infrastructure, network) 
    • The CVSS Exploit vector (network vs physical) 
    • cyber threat intelligence like EPSS and CISA KEV
    • Threat actors leveraging the vulnerability
    • Exploitability factors, if there are exploited in the wild
    • Chatter on the web about the vulnerability
    • Sector-specific considerations
  • Base severity is traditionally cve/cwss score 

Francesco is an internationally renowned public speaker, with multiple interviews in high-profile publications (eg. Forbes), and an author of numerous books and articles, who utilises his platform to evangelize the importance of Cloud security and cutting-edge technologies on a global scale.

Discuss this blog with our community on Slack

Join our AppSec Phoenix community on Slack to discuss this blog and other news with our professional security team

From our Blog

Explore ASPM’s role in modern application security, offering a panoramic view that extends beyond code vulnerabilities. This guide demystifies concepts like traceability, reachability analysis, and asset lineage, pivotal for securing digital assets. Learn how ASPM empowers organizations with actionable insights for precise vulnerability management. #Cybersecurity #ASPM #ApplicationSecurity
Francesco Cipollone
Explore the transformative role of ASPM in cybersecurity. Uncover how Application Security Posture Management aligns business and security objectives for effective vulnerability management and risk reduction. Discover Phoenix Security’s innovative approach to tackling the staggering challenge of CVEs with a strategic focus on prioritization. #ASPM #Cybersecurity #VulnerabilityManagement
Francesco Cipollone
Explore the critical insights into the latest container security vulnerabilities named leaky vessels, including CVE-2024-21626, CVE-2024-23651, CVE-2024-23653, and CVE-2024-23652, BuildKit flaws, with our comprehensive guide on mitigation strategies, best practices for application security, and tips for robust vulnerability management in Docker and Kubernetes environments. Stay ahead in securing your container deployments against potential threats with ASPM help
Francesco Cipollone

Jeevan Singh

Founder of Manicode Security

Jeevan Singh is the Director of Security Engineering at Rippling, with a background spanning various Engineering and Security leadership roles over the course of his career. He’s dedicated to the integration of security practices into software development, working to create a security-aware culture within organizations and imparting security best practices to the team.
In his role, Jeevan handles a range of tasks, from architecting security solutions to collaborating with Engineering Leadership to address security vulnerabilities at scale and embed security into the fabric of the organization.

James Berthoty

Founder of Latio Tech

James Berthoty has over ten years of experience across product and security domains. He founded Latio Tech to help companies find the right security tools for their needs without vendor bias.

Christophe Parisel

Senior Cloud Security Architect

Senior Cloud Security Architect

Chris Romeo

Co-Founder
Security Journey

Chris Romeo is a leading voice and thinker in application security, threat modeling, and security champions and the CEO of Devici and General Partner at Kerr Ventures. Chris hosts the award-winning “Application Security Podcast,” “The Security Table,” and “The Threat Modeling Podcast” and is a highly rated industry speaker and trainer, featured at the RSA Conference, the AppSec Village @ DefCon, OWASP Global AppSec, ISC2 Security Congress, InfoSec World and All Day DevOps. Chris founded Security Journey, a security education company, leading to an exit in 2022. Chris was the Chief Security Advocate at Cisco, spreading security knowledge through education and champion programs. Chris has twenty-six years of security experience, holding positions across the gamut, including application security, security engineering, incident response, and various Executive roles. Chris holds the CISSP and CSSLP certifications.

Jim Manico

Founder of Manicode Security

Jim Manico is the founder of Manicode Security, where he trains software developers on secure coding and security engineering. Jim is also the founder of Brakeman Security, Inc. and an investor/advisor for Signal Sciences. He is the author of Iron-Clad Java: Building Secure Web Applications (McGraw-Hill), a frequent speaker on secure software practices, and a member of the JavaOne Rockstar speaker community. Jim is also a volunteer for and former board member of the OWASP foundation.

Join our Mailing list!

Get all the latest news, exclusive deals, and feature updates.