🌐 Reachability Engine

Introduction of Reachability Engine

Myrror Security’s Reachability Engine is responsible for calculating the reachability of a specifically identified vulnerability. This is done through various methods and steps, as mentioned below.

Through Static Code Analysis of the Source Code and referring to the manifest file (dependency files), Myrror identifies the external dependencies used in the application’s codebase. These dependencies are now checked with the vulnerability database of Myrror Security, which contains publicly and internally disclosed security issues. All the dependencies identified as vulnerable are under the spotlight, and Myrror moves on to calculate the actual impact of each vulnerability.

Purpose of the Reachability Engine

Calculation of the actual impact of the security issue on the application’s codebase has various parameters. Traditional SCA tools use the CVSS score of the vulnerability as the metric for its impact on the application. It is rather inaccurate considering that these are usually marked by public databases not tailored for a particular project.

The severity of the vulnerability is valuable information but is not an overall metric for the impact of the vulnerability. Myrror acknowledges the benefits of this publicly available data but goes much further while calibrating the impact of the security issue on the application.

Myrror’s Reachability Engine performs an extensive scan of the application as well as the dependency, to do a Vulnerability Reachability Analysis on the codebase. This is executed in various steps as given below.

Static Code Analysis: Initiating the Scan

First of all, Static Code Analysis is done on the application’s codebase as left as possible. Here, all the external dependencies that are used are acknowledged. This includes finding the parts where the external dependencies are called from the application’s codebase. These dependencies would be listed and identified if these dependencies contain any security issues. The identified ones would be taken forward to find if the issues in them are reachable. All these tracks are identified by Myrror and a graph is created that would be connected to the external dependencies entry points after the analysis of external dependencies.

Working with External Dependencies

When scanning for external dependencies, extra caution is required because these are not developed by the organization's engineers and are sourced elsewhere. Myrror gathers the dependent sample for testing by using the dependency's final compiled binary. It should be noted that the compiled binary obtained from the package manager is used for analysis rather than the source code of the dependencies. This is because, in their final build, apps employ these built binaries rather than the source code for them. Modern compilers are intended to improve the source code's implementation to produce a binary, hence it is preferable to deal with them rather than the raw source code. This delivers more accurate results for the final application build, which developers value.

However, using the dependencies compiled build rather than the raw source code comes with a trade-off of complexity. Usual Static Code Analysis methods cannot be applied here and require complex mechanisms to decompile and analyze each of them. Fortunately, Myrror Security developed the mechanism for automating this task, providing seamless scanning of dependencies with higher degrees of accuracy and efficiency. Myrror is capable of analyzing compiled packages and hence, allows it to decompile the external dependencies that would be going into the production build and be more accurate about acknowledging what does inside the final application build. This also satisfies transitive dependency analysis, where external dependency relies on other dependencies internally, and Myrror needs to trace it deep into those dependencies.

Binary to Source Code Analysis

This process of decompiling and analyzing the compiled dependencies is called Binary to Source Code Analysis (BSA). In this process, these suspicious dependencies are decompiled, dissected, and analyzed. A graph is created with all the paths connecting to different functions that are found in the dependencies. This graph is referred to as a Call Graph of the dependency. This graph consists of all the paths that lead to each of the functionality, including the external calling of the function or internal calling. This allows Myrror to get a total understanding of the control flow inside the dependency.

Finally, the call graphs for the dependency are connected with the graph obtained with the Static Code Analysis of the Source Code. Gateways that were calling the functions of the dependencies are traced and the reachability of the vulnerable function is calculated. This includes the calculation of paths toward each of the functions and looking out for any traces that lead to calling the vulnerable function.

The End Results

This is done with all the suspicious dependencies and transitively is required. In the end, Myrror holds the required data to provide developers with the application’s codebase that is tailored as per the project itself. Furthermore, this data is used to prioritize the security issue depending on the reachability and severity of the vulnerability.