Our previous article explored the value of reachability analysis with contextual Application Security Posture Management (ASPM) at code and container levels. But this is just one layer of effective prioritization. Another key player, the Exploit Prediction Scoring System (EPSS), adds a predictive edge to vulnerability management by estimating the likelihood of exploitation in the wild.
How does EPSS interact with reachability analysis?
Managed vulnerabilities are not just about finding flaws—they’re about understanding which vulnerabilities are most likely to be exploited and pose the greatest risk. Two powerful tools in this realm are EPSS (Exploit Prediction Scoring System) and reachability analysis, which, when used together, offer a more comprehensive approach to vulnerability management.
Let’s examine how EPSS and reachability analysis complement each other and why using both is essential for prioritizing vulnerabilities like remote code execution (RCE) that can be detected and triggered remotely.
What is EPSS?
EPSS is a predictive scoring tool that assesses the likelihood of exploiting a vulnerability based on global threat intelligence, including data from honeypots and exploitation feeds. This score indicates the potential for exploitation in the wild in the next 30 days, allowing security teams to prioritize based on forecasted threat landscapes. However, EPSS reflects global trends, which don’t always translate directly to risk within your unique environment—this is where reachability analysis makes its mark.
EPSS for libraries and software is less efficient as it works on evidence of exploitation and hence is applicable mostly on vulnerabilities that are traversing the network as Remote Code Execution and whether the fingerprinting feeding the threat intelligence can address those
What is ASPM?
Application Security Posture Management (ASPM), like Phoenix security, is a framework and platform with a comprehensive view of their application security risk across the entire software lifecycle. ASPM platforms like Phoenix Security consolidate and contextualize security data from various sources—including vulnerabilities, misconfigurations, threat intelligence, and exploitability insights—into a single view, empowering security teams to make better-informed prioritization and remediation decisions.
The important difference in ASPM like Phoenix Security is the focus on applying threat intelligence like EPSS at the right level (runtime environment) and reflecting that profile into the software stack. Phoenix security utilizes a 4-dimensional quantitative risk formula to enable the translation of factors like EPSS into the risk of exploitation.
ASPM stands out from traditional security tools by offering:
1. Unified Visibility Across the Application Stack:
ASPM collects data from code, containers, cloud environments, APIs, and runtime operations, providing a holistic view of application security. This all-encompassing approach is essential for modern, complex applications that rely on microservices and containerized architectures.
2. Risk-Based Prioritization and Contextual Analysis:
Unlike conventional vulnerability management solutions, ASPM goes beyond severity scoring. It contextualizes vulnerabilities based on real-world factors such as asset exposure, exploitability, application usage, and even business impact. This allows security teams to prioritize vulnerabilities not only by technical risk but also by their relevance and potential impact on the organization.
3. Integration with Threat Intelligence:
ASPM platforms often incorporate threat intelligence feeds (such as EPSS data) and reachability analysis to gauge the likelihood of exploitation. By integrating these insights, ASPM helps security teams differentiate between theoretical risks and actionable vulnerabilities within their unique environment.
4. Continuous Monitoring and Response:
With ASPM, security postures are continuously assessed, meaning teams receive alerts as new vulnerabilities emerge or existing ones become more exploitable due to changes in the threat landscape. ASPM’s adaptive monitoring also keeps an eye on configuration changes, library updates, and deployment alterations to maintain security resilience.
5. Aligning Security with Business Priorities:
ASPM emphasizes security in the context of business-critical applications. By correlating vulnerabilities with business impact, ASPM supports a security strategy that aligns with organizational goals, enabling faster decision-making and optimizing resource allocation.
Get a demo with your data, test Reachability Analysis and ASPM
Reachability Analysis in ASPM: Contextualizing Vulnerability Risk
Reachability analysis helps organizations understand whether a vulnerability within their codebase, libraries, or containers is exploitable in their specific environment. It assesses whether vulnerable components are reachable within the application’s execution path, providing a local context for the risk posed by each vulnerability.
For example, a critical vulnerability may have a high EPSS score because it’s being actively exploited in the wild. Still, if reachability analysis shows that the vulnerable function is not called in your application, the risk to your organization is minimal. Conversely, a vulnerability with a lower EPSS score might still pose a significant risk if it’s actively used in your code or containerized application, making remediation a priority.
Using EPSS and Reachability Analysis in ASPM Together: A Powerful Combination
While EPSS gives you a global view of the likelihood of a vulnerability being exploited, reachability analysis provides the local context to determine whether the vulnerability is relevant to your specific environment. Combining these two approaches, like Phoenix Security ASPM, can create a more nuanced risk-based prioritization strategy.
1. Remote Code Execution (RCE) and Detecting Exploitable Vulnerabilities
One of the key areas where EPSS and reachability analysis work hand-in-hand is in identifying remote code execution (RCE) vulnerabilities, like Log4j or Spring4Shell. RCE vulnerabilities are critical because they allow attackers to execute arbitrary code on a remote system, often with minimal user interaction.
• EPSS helps identify RCE vulnerabilities actively exploited in the wild based on data collected from honeynets and threat intelligence sources.
• Reachability analysis adds value by determining whether the vulnerable library or function is being used in your specific application or container. this is where an ASPM like Phoenix Security helps combine the two factors
For example, the high EPSS score of Log4j made it a priority for many teams, but reachability analysis could show if your application specifically calls vulnerable Log4j functions, informing whether immediate remediation is needed. The combination ensures that vulnerabilities are relevant both in exploitability and application usage.
More analysis of the methods used and exploited in vulnerability:
CISA KEV: https://phoenix.security/what-is-cisa-kev-main/
Exploit in the wild: https://phoenix.security/what-is-exploitability/
OWASP/Appsec Vulnerability: https://phoenix.security/what-is-owasp-main/
CWE/Appsec Vulnerabilities: https://phoenix.security/what-is-cwe-main/
2. Local Risk in ASPM: Context for Library and Container Use
While EPSS is useful for identifying widely exploited vulnerabilities, not every vulnerability flagged by EPSS is immediately exploitable in your environment. This is particularly true for libraries and containers. Sometimes, a library might have a low EPSS score because it’s rarely exploited in the wild. Still, reachability analysis could reveal that this library is actively used in your containers or deployed applications, elevating its risk profile.
In these situations, reachability analysis complements EPSS by giving visibility into whether vulnerable code is in use, helping you determine the real-world risk to your systems. This is especially important for vulnerabilities in libraries used by containerized applications, where vulnerabilities might not be exploited directly but could be triggered in specific contexts, such as over-permissioned configurations.
3. Cross-Comparing Data for More Accurate Prioritization with ASPM
I always say that using multiple data sets like EPSS and reachability analysis offers a more holistic understanding of risk. By cross-referencing EPSS data with reachability analysis, security teams can avoid wasting time on vulnerabilities that are unlikely to be exploited while focusing on those that represent real, immediate threats.
For example:
• EPSS might indicate that a particular vulnerability has a low probability of exploitation across the internet. Still, if reachability analysis shows that your application uses a vulnerable library in a critical service, the risk is higher for your organization.
• On the other hand, EPSS might flag a vulnerability with a high probability of exploitation. Still, if reachability analysis confirms that the vulnerable function isn’t being called in your code or container, you can deprioritize it.
This combined approach, used by advanced ASPMs like Phoenix Security, allows security teams to make informed, data-driven decisions about which vulnerabilities to address first, improving overall security posture and making vulnerability management more efficient.
Phoenix Security’s Approach: Integrating EPSS and Reachability Analysis
Phoenix Security takes a risk-based approach to vulnerability management by combining EPSS with advanced reachability analysis. Phoenix’s platform evaluates vulnerabilities based on both global exploitation trends (from EPSS) and local application-specific contexts (through reachability analysis).
This dual-layered approach ensures that vulnerabilities are prioritized based on their likelihood of being exploited globally and their relevance and impact in your specific environment.
• For RCE vulnerabilities like Log4j, Phoenix Security uses EPSS to identify high-risk vulnerabilities being exploited in the wild. At the same time, reachability analysis confirms whether these vulnerabilities are exploitable within your code or running applications.
• For libraries and containers, Phoenix Security uses reachability analysis to assess whether vulnerabilities flagged by EPSS are relevant to your deployment, allowing for more precise prioritization.
By leveraging EPSS and reachability analysis, Phoenix Security helps security teams reduce noise, focus on actionable vulnerabilities, and improve their overall risk management process.
Real case scenario combining EPSS, Static Reachability, Contextual Reachability
In contextual reachability analysis, another factor reduces the reachability of exploitation in conjunction with EPSS. The likelihood of exploitation and the reachability at the system level play two important roles: communicating how likely a system will be exploited without network reachability and compensating controls.
Integrating contextual reachability analysis, the systems above might be exploited internally.
The two combined factors of EPSS and reachability analysis communicate if a system’s vulnerability is reachable and exploited in the wild. Nonetheless, as mentioned before, the fact that a vulnerability is not exploited in the wild does not mean that the risk of exploitation is not there, which means that there was no evidence of using that vulnerability. The vulnerability for a library needs to be exploited remotely or used in a network attack vector to be detectable by EPSS in a meaningful way; other factors are described in the table below.
Nonetheless, a function’s reachability at the library or container level provides a stronger indicator of a vulnerability’s disablement, and even more so when used in conjunction with Contextual runtime detection, like Phoenix Security’s ASPM contextual analysis of runtime libraries.
For example, in a library used in a system that is loaded in a production container (snakeyaml 0.0.34 suffers from vulnerability CVE-2022-1471), the library is present in both code (as detected by snyk SCA (1) ) and runtime as detected by sysdig (2). The deployment relationship (A) contextually links the two libraries.
Both static reachability (1) and deployment reachability (2) are important as they communicate that the library is actually used in code, loaded in one or multiple images (2), and loaded in multiple running containers (B).
Nonetheless, the evidence of exploitation for those containers from the EPSS perspective is LOW (2.1%), as there is no evidence of exploitation in the wild, and this vulnerability is unlikely to be exploited remotely. Also, the containers are running in a partially exposed environment (4)
This analysis shows that the vulnerability is loaded in production and reachable but with low evidence of exploitation. Hence, the fact that the library is loaded in operation and reachable at the code level increases the likelihood of exploiting the vulnerability.
Phoenix currently allows the detection of libraries running in code and in runtime to contextually deduplicate and prioritize the vulnerabilities used in production. However, it also considers contextual reachability from the configuration of integrated scanners like Wiz, compensating controls, and EPSS evidence of exploitation in a single 4-dimensional quantitative risk formula.
Phoenix Security’s 4D Contextual Risk Formula
Phoenix utilizes a simple structure of probability of exploitation, base severity, and impact analysis.
Phoenix Security’s 4D contextual risk formula goes beyond traditional vulnerability scoring by considering multiple factors:
- Vulnerability Severity: How critical is the vulnerability
- Dynamic Reachability: Is the vulnerability actively exploitable in the application environment? Is the vulnerability weaponized and automatically utilized in the wild to launch large-scale attacks
- Threat Intelligence: Are there active exploits for this vulnerability in the wild? Is there evidence of exploitation
- Contextual Data: What is the context of the application’s environment, how external are the assets where the application is deployed, and how impactful are the aggregated application
Contextual Reachability AI: Phoenix adopts contextual reachability analysis to reduce the number of vulnerabilities and transfer the contextual risk when a library is used in production.
Business Impact and Damage calculation: How much damage can an organization suffer if the vulnerabilities are exploited?
By correlating these four dimensions, Phoenix Security offers a more nuanced risk score, allowing for smarter, more targeted vulnerability management.
Those prioritization concepts are also explained in the book: https://phoenix.security/whitepapers-resources/ebook-aspm-programs-appsec/
Conclusion: EPSS and Reachability Analysis – A Perfect Pair for Modern Vulnerability Management
Relying on a single data set for vulnerability management can lead to inefficiencies and missed risks in today’s complex application ecosystems. EPSS offers valuable insights into global exploitation trends, while reachability analysis provides the local context to assess whether those vulnerabilities are relevant to your specific environment.
Together, EPSS and reachability analysis offer a comprehensive approach to vulnerability prioritization, helping security teams focus on vulnerabilities that are exploitable in the wild and actively used in their applications. This combination is especially critical for identifying and addressing remote code execution (RCE) vulnerabilities, which can be detected and triggered remotely.
By integrating EPSS and reachability analysis, Phoenix Security empowers organizations to take a smarter, more targeted approach to vulnerability management, ensuring that the most critical risks are addressed first.
Stay safe, stay informed, and use both EPSS and reachability analysis for a complete view of your security posture.
Minimize the vulnerability risk and act on the vulnerabilities that matter most, combining ASPM, EPSS, and reachability analysis.
Organizations often face an overwhelming volume of security alerts, including false positives and duplicate vulnerabilities, which can distract from real threats. Traditional tools may overwhelm engineers with lengthy, misaligned lists that fail to reflect business objectives or the risk tolerance of product owners.
Phoenix Security offers a transformative solution through its Actionable Application Security Posture Management (ASPM), powered by AI-based Contextual Quantitative analysis. This innovative approach correlates runtime data, combines it with EPSS and other threat intelligence, and applies the right risk to code and cloud, delivering a prioritized list of vulnerabilities.
Why do people talk about Phoenix Security ASPM?
• Automated Triage: Phoenix streamlines the triage process using a customizable 4D risk formula, ensuring critical vulnerabilities are addressed promptly by the right teams.
• Actionable Threat Intelligence: Phoenix provides real-time insights into vulnerabilities’ exploitability, leveraging EPS and combining runtime threat intelligence with application security data for precise risk mitigation.
• Contextual Deduplication with reachability analysis: Utilizing canary token-based traceability for network reachability and static and dynamic runtime reachability, Phoenix accurately deduplicates and tracks vulnerabilities within application code and deployment environments, allowing teams to concentrate on genuine threats.
By leveraging Phoenix Security, you not only unravel the potential threats but also take a significant stride in vulnerability management, ensuring your application security remains current and focuses on the key vulnerabilities.