Rebuilding Trust In The Alert Stack With Reachability Analysis
-
November 6, 2023
Introduction
In the realm of software development managing dependencies is a critical yet challenging task. Developers frequently integrate third-party libraries and packages to accelerate the development process, sometimes unknowingly introducing potential vulnerabilities and operational risks into their codebase. Traditional tools and methods for tracking and managing these dependencies often fall short, leaving developers grappling with a slew of updates and security patches. The complexity multiplies when considering transitive dependencies, or dependencies that have their own dependencies (that may be vulnerable themselves), making it arduous to assess the impact of a single update or vulnerability on the entire application.
This is where the concept of reachability comes to the rescue. Reachability analysis provides a nuanced approach to understanding how different parts of a codebase interact with each other and with external dependencies. By understanding all possible paths from one function to another, reachability analysis can precisely identify which parts of the code are affected by a change or vulnerability in a dependency. This level of detail is crucial for appsec professionals to prioritize updates and security fixes effectively, ensuring that efforts are directed where they are needed most.
Solving the problem of reachability transforms the way developers approach dependency management and security. Instead of being overwhelmed by a barrage of alerts and updates, application security professionals and developers alike can now focus on what truly matters: ensuring that their code is robust, secure, and efficient. By leveraging reachability analysis, developers can navigate the intricate web of dependencies with confidence and precision, leading to more resilient and reliable software applications.
An Uphill Battle: The Undertaking of Reachability Analysis
Determining code-based reachability is a multifaceted challenge that delves into the intricate relationships between different parts of a software application. The task involves tracing potential paths from one function to another within the codebase and its dependencies. This process is complicated by the presence of dynamic function calls, polymorphism, and other programming constructs that introduce variability and uncertainty in the flow of execution. As a result, the resulting information of this manual exercise is often an over-approximation, indicating potential calls that may never occur in actual execution.
This task of tracing code-level interactions involves understanding the intricacies of control flows, conditional statements, and function calls. Developers must scrutinize the code to identify potential vulnerabilities and assess whether a particular path is likely to be executed in real-world scenarios. To accurately calculate reachability, static analysis techniques must be employed to scrutinize the code without executing it. This involves parsing the code, understanding control flows, and identifying function calls, including those that are nested within conditions or loops. The precision of static analysis is often challenged by language semantics, indirect calls, and external libraries. Consequently, analysts must strike a delicate balance between over-approximation, which could lead to false positives, and under-approximation, which might overlook certain paths.
Despite these complexities, calculating code-based reachability is crucial for identifying vulnerabilities and ensuring secure coding practices. By understanding which parts of the code can potentially interact with a vulnerable function, developers can prioritize fixes and updates effectively. The difficulty in calculating reachability underscores the need for sophisticated tools and methodologies that can navigate the complexities of modern programming languages and software architectures.
The VEX Standard: A Leap Forward in Understanding Reachability
The introduction of the Vulnerability Exploitability Exchange (VEX) standard marks a significant advancement in the realm of application security and software dependency management. VEX provides a standardized format for disclosing vulnerability and risk information related to specific software applications. By enabling application authors to transparently communicate whether their software packages are susceptible to known vulnerabilities, VEX facilitates a more informed and nuanced approach to assessing security risks.
VEX serves as a valuable tool in refining 'last mile' reachability calculations. Traditionally, determining the reachability of a vulnerability within a codebase required extensive analysis and often led to either overestimations or underestimations of potential risks. With VEX, application authors (and others) can provide precise information about the exploitability of vulnerabilities within their software, thereby reducing ambiguity. This information can be integrated into reachability analyses to provide a more accurate and context-specific understanding of potential security threats. For instance, if a vulnerability is disclosed but the application author confirms that it is not exploitable in their package, security teams can deprioritize it in their calculation and remediation efforts.
In essence, the VEX standard acts as a bridge between generic vulnerability databases and the specific context of an application. By providing a mechanism for tailored vulnerability disclosures, VEX enhances the accuracy of reachability calculations and allows for more targeted and effective security practices.
Reachability In Action
To truly grasp the concept of code-based reachability, it is essential to observe it in action within real-world scenarios. Reachability analysis delves into the intricate pathways of code execution, determining whether a particular segment of code, such as a function or library, can actually be invoked during runtime. By examining concrete examples, we can better appreciate how reachability analysis aids in distinguishing between genuine threats and false positives, thereby streamlining the efforts of application security professionals. Let's explore some instances that illustrate the pivotal role of reachability in enhancing the precision and efficiency of security assessments.
Example 1: The Phantom Threat
Consider a scenario where a Software Composition Analysis (SCA) tool identifies a high-risk vulnerability in a third-party library that an application imports. The library in question is known to have a severe security flaw, and its mere presence in the codebase triggers an immediate high-severity alert.
Importing the Vulnerable Library
# app.py
import vulnerable_library
def main():
print("Hello, World!")
if __name__ == "__main__":
main()
In this example, vulnerable_library is known to have a critical security vulnerability, and its importation raises a red flag in most tools. The alert suggests that the application is at high risk due to the inclusion of this library.
The Unused Library
# vulnerable_library.py
def risky_function():
# Code that contains a high-risk vulnerability
pass
Upon closer inspection, however, it becomes evident that the application never actually calls any function from vulnerable_library. The library, perhaps once used, has been orphaned in the declarations and is no longer part of the application's active codebase.
The Application in Action
# app.py
import vulnerable_library
def main():
print("Hello, World!")
if __name__ == "__main__":
main()
In this scenario, even though the vulnerable_library is imported, the risky_function() is never invoked. Thus, the actual risk to the application is nonexistent, despite the high-severity alert generated by the SCA tool.
This example illustrates a common challenge faced by application security professionals. The initial alert necessitates an investigation to determine the actual risk, consuming valuable time and resources. Such prioritization failures and false positives underscore the importance of reachability analysis in accurately assessing and prioritizing security vulnerabilities.
Example 2: The Power of VEX in Reachability Analysis
In this scenario, let's explore how the integration of the Vulnerability Exploitability Exchange (VEX) standard can enhance reachability analysis and streamline the process of identifying and prioritizing security threats.
Importing a Library with a Known Vulnerability
# app.py
import library_with_known_vulnerability
def main():
print("Secure Application!")
if __name__ == "__main__":
main()
Here, library_with_known_vulnerability is flagged due to a known high-severity vulnerability. Traditionally, this would necessitate an immediate and time-consuming investigation.
The Library with a Known Vulnerability
# library_with_known_vulnerability.py
def vulnerable_function():
# Code that contains a high-risk vulnerability
pass
The Application in Action
# app.py
import library_with_known_vulnerability
def main():
print("Secure Application!")
if __name__ == "__main__":
main()
Upon initial inspection, it seems that the application is at risk due to the importation of library_with_known_vulnerability. However, the vulnerable_function() is never called, suggesting that the risk might be overestimated.
VEX Document: Clarifying the Risk
{
"vulnerabilityID": "CVE-1234-5678",
"packageName": "library_with_known_vulnerability",
"version": "1.0.0",
"exploitability": "Not Affected"
}
In this case, the VEX document associated with library_with_known_vulnerability indicates that, despite the known vulnerability, the specific version used by the application is not affected. An author might designate the 'Not Affected' tag for exploitability in a VEX document for several reasons. Firstly, the vulnerability in question may have been identified but determined to be non-exploitable in the context of the specific software package or version. For instance, the vulnerability could be contingent on certain configurations or conditions that are not present in the package. Secondly, the author might have implemented mitigations or safeguards within the application that neutralize the threat, rendering the vulnerability ineffective. Additionally, the vulnerability might be related to a feature or component that is deprecated or unused in the package, thereby posing no real threat. By using the 'Not Affected' tag, the author effectively communicates that, despite the presence of a known vulnerability, the software package remains secure and unexploitable in its current state. This crucial piece of information, when combined with reachability analysis, quickly clarifies that the application is not at risk.
Conclusion
Application security professionals find themselves navigating through endless high-severity alerts, many of which turn out to be prioritized incorrectly, or are false positives. The sheer volume of these alerts can be overwhelming, underscoring the urgent need for more precision and accuracy in vulnerability assessments. Reachability analysis, when complemented by the rich contextual information provided by the Vulnerability Exploitability Exchange (VEX) standard, emerges as a powerful solution to this challenge.
The VEX standard empowers developers and security professionals to discern the true impact and exploitability of vulnerabilities within software packages. By integrating reachability analysis with VEX documents, it becomes possible to meticulously trace whether a potentially vulnerable piece of code is actually invoked, and if so, whether it is genuinely at risk. This synergy significantly reduces the noise created by false positives, allowing security teams to prioritize and focus on addressing genuine threats.
Backslash Security and Reachability Analysis
Pivotal in Backslash's capabilities is reachability analysis. By integrating many signals including those from infrastructure, code reachability, VEX, and more, Backslash remarkably minimizes vulnerabilities, identifying a staggering 100x fewer issues while finding the ones that truly matter.
Backslash platform assists Appsec in combating vulnerability burnout. See it in action!
.png)
