OpenText Core SCA's Reachability Analysis helps you automatically determine if a vulnerability in a library affects your project. It analyzes which parts of the library are vulnerable and checks if your code uses those parts. To do this, OpenText Core SCA needs to understand how your open source dependencies are used. This information is collected by using OpenText Core SCA's CLI tool to generate a call graph for your project. For instructions on creating the required call graph, see how to Set up Reachability Analysis for Java.

How does OpenText Core SCA know the vulnerable parts of libraries?

OpenText Core SCA identifies vulnerable parts of libraries through the following steps:

1. Fetch the relevant versions: Retrieve the latest vulnerable version and the first fixed version from OpenText Core SCA's database.

2. Pinpoint the smallest change: Use information from various sources to narrow down to two specific versions — one that is vulnerable and one that is fixed. These versions can be released versions, Git tags, Git commits, or similar.

3. Analyze code differences: Download the code for these two versions, identify the changes between them, and translate these changes into functions, classes, and other code symbols. Store this information in OpenText Core SCA's database.

Am I using vulnerable parts?

To perform the analysis, OpenText Core SCA needs to know which parts of a library are vulnerable and whether your code uses those parts. This is determined by generating a call graph for your program and its libraries. The call graph is then uploaded along with your dependency files and scanned for the vulnerable symbols identified in the previous step.

• If vulnerable symbols are found: This indicates that your code uses the parts of the library affected by the vulnerability, meaning your project is likely at risk.

• If vulnerable symbols are not found: This suggests that your code probably does not use the vulnerable parts and is less likely to be affected.

Examples

For projects using Netty versions between 4.1.0 and 4.1.43, OpenText Core SCA's public vulnerability database identifies the following vulnerabilities:

• CVE-2019-20444

• CVE-2019-20445

• CVE-2020-11612

However, not all of these vulnerabilities may affect your project:

• CVE-2019-20444 and CVE-2019-20445 impact the web server component of Netty.

• CVE-2020-11612 affects decompression functionality.

If your project does not use Netty for decompression, CVE-2020-11612 will not pose a risk. In this case, upgrading to version 4.1.44 instead of 4.1.46 might be sufficient. Similarly, if your project does not use the web server part of Netty, an upgrade might not be necessary at all, saving significant time and resources. However, it is still recommended to upgrade to a safe version, even if the priority may be lower when vulnerable symbols are not in use. Normally, determining this would require manual investigation, involving a deep understanding of both your project and Netty, as well as reviewing CVE specifications to find which parts of Netty are affected. With OpenText Core SCA's Reachability Analysis, this process is fully automated.

Different statuses of OpenText Core SCA Reachability Analysis

In the tool, a vulnerability can have one of the following Reachability Analysis statuses:

• Found: The vulnerable functionality was detected as reachable through your code.

• Not Found: The vulnerable functionality was not detected as reachable through your code.

• Missing data: There is not enough information available to determine if the vulnerable functionality is reachable.

• Unknown: The analysis was not run for this commit and vulnerability.

To enable Reachability Analysis for Java, you need to generate a call graph. This can be done using the OpenText Core SCA CLI callgraph command, which can be added to your integration, so that it is generated appropriately before making a OpenText Core SCA scan. To find out more about the command and the various available flags, run:

Reachability Analysis is supported for all Java projects using Maven. To produce a callgraph, OpenText Core SCA requires the compiled code for your project and access to the libraries it uses. By default, the command will attempt to do all the preparation work for the command to be successful. The success of the preparation depends on the specific project structure and configurations. In the event of failure, it is possible to configure the command not to run the preparation steps using the --no-build flag, and instead set it up separately before running the command.

Set up call graph generation in your pipeline

When successful, the callgraph command will generate a debricked-call-graph file that is automatically picked up when running the debricked scan command and sent to OpenText Core SCA, together with the dependency files, for analysis. For many projects, it will be possible to run the default configuration of the callgraph command, doing the preparation steps as part of the command. In this case, all that is needed is to add running debricked callgraph in your configuration, before running the scan, ensuring that the scan has access to the generated call graph file. For GitHub Action integrations, there is also Actions setup that can be found in the .

If the build step of the callgraph command fails, or if you are already building the project in a previous stage of the pipeline, it’s highly recommended to build the project separately before running the callgraph command with the —no-build flag. Just make sure that the files resulting from the build are included in the stage where call graph generation is run.

The examples below use a OpenText Core SCA CLI docker image to ensure that there is a compatible maven version included for the commands to succeed. OpenText Core SCA recommendation is that you incorporate the scan and callgraph commands in your build image/steps whenever possible, to ensure that versions of the underlying tools correlate with your environment.

Example: Building the project during the callgraph command

In this example, the callgraph command is run with its default configuration, which builds the project and prepares the necessary files automatically before generating the call graph.

Example: Using a separate build step

The example below is using maven to build the project and generate the files needed for call graph generation. The generated files must be reachable in the stage where the callgraph command is run, so that it has all pre-requisites to be run successfully.

Common issues

Multiple issues can occur when trying to generate the callgraph which prohibits success. Some common issues are:

• Unsupported Java version. If your project requires a Java version older than 11, Debricked may not be able to produce a callgraph. Debricked may also not be able to generate a callgraph if your project uses new lanugage features from a version above 21.

• Unsupported language features. Some advanced language features can make callgraph generation impossible for the tool that is used to generate the callgraphs.

Reachability Analysis is supported for all Go projects. You need the compiled code and the libraries used by your Go project to enable Reachability Analysis.

You need to generate a call graph to enable Reachability Analysis for Go. To generate a call graph, add the OpenText Core SCA CLI callgraph command to your integration before running a OpenText Core SCA scan. To find out more about the command and the various available flags, run:

debricked callgraph -h

When successful, the callgraph command generates a debricked-call-graph file. This file is automatically sent to OpenText Core SCA with the dependency files for analysis, when running the debricked scan command.

Set up call graph generation in your pipeline

For many projects, running the callgraph command with the default configuration might be enough to run the preparation steps. In this case, before running the debricked scan, to add the command to run debricked callgraph in your configuration to ensure that the scan has access to the generated call graph file.

For GitHub Action integrations, OpenText Core SCA must also add Actions setup that can be found in the .

Example: Building the project during the callgraph command

In this example, the callgraph command is run with default configuration to build the project and prepare the necessary files automatically before generating the call graph.