Reachability Analysis with Bamboo

You can configure Sonatype for Bamboo Data Center to perform Reachability Analysis, which can detect method signatures in your application code that contain components with potentially exploitable security vulnerabilities. Policy violations occurring due to these vulnerable components are labeled as Reachable and can be viewed on the application report.

By including additional parameters in the Lifecycle Policy Evaluation task you can enable the Reachability Analysis feature. The scan process will then analyze all application and dependency Java (or any JVM language) binaries located in the scan target. This allows you to detect reachable vulnerabilities, even in proprietary components within your application.

Permissions Required

Sonatype for Bamboo Data Center users should have the Evaluate Applications permissions to scan applications with Reachability Analysis.

To enable Reachability Analysis for Java, install or update the Sonatype for Bamboo Data Center plugin to version 3.2.0 or later on the Bamboo DC instance that runs your project builds.

Using Java Reachability Analysis on Bamboo DC

For Best Results with Reachability Analysis

Results for Reachability Analysis depend on the strategy used to select the types of methods to scan and the selection of namespaces to narrow down the scan entry points.

Use the parameters below to enable Reachability Analysis for your builds. Select Enable Java reachability analysis; all other parameters are optional.

Analysis Algorithm

These are the supported algorithms for Java reachability analysis:

Note

Sonatype recommends keeping the default (RTA_PLUS). Do not change this setting unless directed by Sonatype Support.

CHA (Class Hierarchy Analysis): A static call analysis that considers all methods in all possible loaded subclasses.
RTA (Rapid Type Analysis): Similar to CHA, but improves precision by analyzing only classes instantiated during program execution.
RTA_PLUS: Sonatype’s version of RTA, offering even greater precision and serving as the default algorithm.

Includes

Multi-module projects could have several .jar files when built. Many of these .jar files are dependencies of another .jar file, which could be the one containing the main application. By specifying the path to this specific .jar when running reachability analysis, you can avoid multiple evaluations of the same .jar files, which would occur when:

.jar files are evaluated separately.
.jar files are evaluated when invoked by the main application.

The includes parameter specifies a target path for the artifacts to be analyzed. It limits the scope of the analysis, resulting in better precision and reducing the utilization of system resources. E.g. target/**/*.jar.

If the includes parameter is omitted, the target location for the analysis will be the same as specified in the Scan Targets parameter. This may increase the scope of the target analysis, leading to reduced precision.

Entrypoint Strategy

When Reachability Analysis is enabled in Bamboo, you can choose one of the following strategies:

JAVA_MAIN:Selects all methods matching public static void main(String[] args).

PUBLIC_CONCRETE: Selects public non-abstract/synthetic methods from non-interface/annotation classes.

ACCESSIBLE_CONCRETE: Selects public/protected non-abstract/synthetic methods from non-interface/annotation classes.

CONCRETE: Selects all non-abstract/synthetic methods from non-interface/annotation classes. This is the default entrypoint strategy.

ALL: Selects all methods from all non-interface/annotation classes.

Namespaces

Select the methods that should be considered as entry points (points in code where execution begins) for the analysis.

Namespaces are specified at the level of packages. All packages nested under a namespace are considered for entry point selection. If multiple namespaces are specified, all of them will be included.

Reachability Analysis will start with the namespaces specified and subsequently analyze all others in the execution path.

Example:

Consider the following project structure:

	src
	|—main
	|	|—java
	|	|	|—com
	|	|	|	|—example
	|	|	|	|	|—iq
	|	|	|	|	|	|—domain
	|	|	|	|	|	|	|—DomainClassOne.java
	|	|	|	|	|	|—application
	|	|	|	|	|	|—repository
	|	|	|	|	|—wrappers
	|	|	|	|	|	|—OktaLoginWrapper.java
	|	|	|	|	|—configs
	|—test
	|	|—java
	|	|	|—com
	|	|	|	|—example
	|	|	|	|	|—iq
	|	|	|	|	|	|—domain
	|	|	|	|	|	|	|—DomainClassOne.java
	|	|	|	|	|	|—application
	|	|	|	|	|	|—repository
	|	|	|	|	|—wrappers
	|	|	|	|	|	|—OktaLoginWrapper.java
	|	|	|	|	|—configs

The namespaces parameter is configured as follows: com.example.iq.

In the example above, the namespaces property specifies the namespace 'com.example.iq', which will be considered as the entry point for the analysis. This namespace has domain, application, and repository packages under its scope. Methods belonging to DomainClassOne.java class (under the domain package in the 'com.example.iq' namespace) will be analyzed before other methods in the package classes. Similarly, methods belonging to classes under other applications and repository packages will be analyzed at the start of the analysis for the package.

Packages of type wrappers, with namespace 'com.example.wrappers' and config packages with namespace 'com.example.configs' will be omitted when an entry point for the analysis is being established. Similarly, methods belonging to the OktaLoginWrapper class with namespace 'com.example.wrappers.OktaLoginWrapper.java' will be omitted when establishing an entry point.

Notes:

An entry point is any method signature that aligns with the selected strategy. For example, for JAVA_MAIN strategy, all entry point methods have public static void main as method signature.
You can use regular expressions when specifying the namespace.
Example: For org.foo.example, you can use regular expressions with '/' at the start and end of the string as /^org\\.+.*\\.example\$/.
Specify at least one namespace (prefer your app’s root package, e.g., org.foo.example).
If namespaces are omitted, reachability attempts to derive them from Lifecycle Proprietary Component Configuration (Package/Regex). If nothing is defined there, a warning is logged, no entry-points are discovered, and the run fails with "At least one entry-point required".