π Reachability Analysis
In security, focusing solely on detecting vulnerabilities by comparing them with public severity scores can be misleading. Since these vulnerability databases provide information about the specific vulnerabilities and mention the public impact on large cases, they cannot measure the impact on the specific project your organization is working on.
To fine-tailor the prioritization as per your project, Myrror Security implements Reachability Analysis in their SCA, which not only is more accurate in terms of identifying security issues but also prioritizing them as per the actual impact measured by it for the specific project itself.
What is Reachability Analysis?
Reachability Analysis, in the context of Myrror Security, is a process that examines the attack surface of your applications and determines whether a detected vulnerability can be realistically accessed and exploited by an attacker within your specific network environment. In the context of cybersecurity, it analyzes the code within your applications to determine if a vulnerability can be realistically exploited by an attacker.
Why is Reachability Analysis Important?
Traditional methods implemented by vulnerability scanners use public database records of vulnerabilities with parameters such as severity and impact score. Although these parameters are crucial for understanding the impact on a global level, itβs not fine-tuned for your specific project. Using public database records to compare the application codebase can create lots of alerts, without any prioritization of the issues. Even if priority is provided, itβs backed by the public database and is usually inaccurate since it is not being calculated as per the codebase. This overwhelming amount of detection of security issues, paired with inaccurate data leads to slowing down the development process of the organization and wastes a lot of developerβs efforts and time. This term is coined as βAlert Fatigueβ. Reachability Analysis, in the context of prioritization, includes the methodology for calculating the impact of security issues on the codebase and providing developers with a list of security issues that must be addressed as per the order of severity and reachability of that issue within the codebase, solving the issue of flooding developers with a list of issues with inaccuracy. In the end, developers donβt have to care about prioritization or remediation planning, and their entire focus is on patching them, effortlessly.
Following are some of the features included in Prioritization of Issues with Reachability Analysis:
- Prioritization: By filtering out unreachable vulnerabilities, Reachability Analysis allows you to prioritize your remediation efforts on the most critical issues that could be exploited within your environment. This saves valuable time and resources and prevents Alert Fatigue among developers, allowing efficient and effortless addressing of security issues.
- Reduced False Positives: Traditional vulnerability scanners can sometimes flag vulnerabilities that are not actually exploitable due to specific code configurations or security measures in place. Reachability Analysis helps eliminate these false positives, providing a clearer picture of your true security posture.
- Improved Efficiency: Focusing on reachable vulnerabilities allows your security teams to work more efficiently. They can concentrate their efforts on developing remediation strategies for the most critical threats, leading to faster and more effective risk mitigation.
How Does Reachability Analysis Work?
When identifying security issues in the application, Myrror uses its Reachability Analysis Engine to walk through all the paths and edges of the application. This includes various phases and approaches to scan for issues. This begins with scanning for the dependencies file (the manifest file) to acknowledge the dependencies in use and identify security issues in every dependency. Then, the entry points (parts in the codebase where suspected vulnerable packages are called) towards these vulnerable dependencies are identified. Since we only care about the security issues that are in the final build, which are actually responsible for causing real threats, Myrror analyses the final compiled builds of the dependencies, straight from the repository from where they would be called while bundling the final application build. The compiled build packages are decompiled and analyzed and all entry points to each of the functions are taken into consideration. Finally, all the known entry points in the application codebase are mapped with the entry points to vulnerable functions.
If the vulnerable portion of the compiled dependency falls in the path of execution of the application, that specific dependency is considered as reachable and a security threat to the application.
All these issues that are reachable are sorted with their severity and are prioritized at the top. Although issues that are not reachable have no impact on the final application build, they are prioritized as per their severity and prioritized at the end of the ones that are actually reachable. Furthermore, Myrror pairs all the security issues in the sorted list with their remediation plan and all this data is compiled into security reports, and delivered to the developers and security teams of the organization. By combining these techniques, Myrror Security's Reachability Analysis empowers you to make informed decisions about vulnerability remediation, prioritizing the most critical threats and ensuring a more efficient and effective security posture.
Example of a Reachable Vulnerability found by Myrror Security
The following process mentioned is automated by Myrror and the final results are presented in an interactive and in-depth report as shown in the image below. Here, a Code Injection is Detected in the BouncyCastle dependency in the repositories. Here, Myrror has identified this vulnerability to be reachable and have a critical impact on the security posture of the application. Furthermore, an explanation of its reachability and its impact is provided in detail in the report.