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 application code and dependencies in the scan target for Java (or any JVM language) and JavaScript/TypeScript projects. 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.

Reachability Evidence
When Sonatype for Bamboo Data Center runs a Java scan with reachability enabled, call path evidence is sent to IQ Server and displayed in the violation details view. See Reachability Evidence for details.

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".

Using JavaScript Reachability Analysis on Bamboo DC

JavaScript Reachability Analysis detects exploitable vulnerabilities in JavaScript/TypeScript application dependencies by analyzing your application code and identifying which vulnerable dependency methods are actually called during execution.

JavaScript Reachability Prerequisites

If you plan to use JavaScript Reachability Analysis, ensure the following prerequisites are met before configuring the plugin:

Node.js Installation

JavaScript Reachability Analysis requires Node.js to be installed on the Bamboo build agents where analysis will run.

• Installation: Install Node.js on each Bamboo agent that will execute JavaScript Reachability Analysis.

• System PATH: If Node.js is installed in the system PATH, the plugin will automatically detect it. No additional configuration is required.

• Custom Path: If Node.js is installed in a non-standard location, you can specify the full path to the Node.js executable in the task configuration.

Project Structure Requirements

For JavaScript Reachability Analysis to function correctly, your project must include:

• package.json: A valid package.json file must exist in your project root or the specified project directory. This file defines your JavaScript dependencies.

• Installed Dependencies: Node modules must be installed (via npm install, yarn install, or similar) before reachability analysis runs. Consider adding a dependency installation step before the Lifecycle task in your build plan.

• Source Files: Your application source code must be accessible within the Bamboo workspace.

Enabling JavaScript Reachability

To enable JavaScript reachability analysis in your Bamboo task configuration:

1. Navigate to your build plan and select the Sonatype Lifecycle task.

2. In the Reachability Analysis section, locate JavaScript Reachability Analysis and select it.

3. Configure the required and optional parameters described below.

Configuration Parameters

Source File Patterns (Required)

Specifies glob patterns identifying which JavaScript or TypeScript files contain your application code. Multiple patterns can be specified, one per line.

• Format: Ant-style glob patterns (e.g., **/*.js, src/**/*.ts), relative to the project root directory.

• Required: Yes - at least one pattern must be specified.

• Bamboo Variables: Supported (e.g., ${bamboo.build.working.directory}/src/**/*.js).

• Examples:

src/**/*.js
lib/**/*.ts
app/**/*.{js,ts}

Exclude File Patterns (Optional)

Specifies glob patterns for files or directories to exclude from analysis. Use this to skip test files, build artifacts, or other non-application code.

• Format: Ant-style glob patterns, relative to the project root directory.

• Required: No.

• Bamboo Variables: Supported.

• Examples:

**/node_modules/**
**/*.test.js
**/dist/**
**/build/**

Node.js Path (Optional)

Specifies the full path to the Node.js executable if it is not available in the system PATH.

• Format: Absolute file path to the Node.js executable.

• Required: No (uses system PATH if not specified).

• Bamboo Variables: Supported.

• Examples:

• Linux/macOS:/usr/local/bin/node

  • Windows:C:\Program Files\nodejs\node.exe

• When to Use: Specify this when Node.js is installed in a non-standard location or when multiple Node.js versions exist on the build agent.

Project Root Directory (Optional)

Specifies the directory containing your project's package.json file, relative to the Bamboo workspace root.

• Format: Relative path from the workspace root.

• Required: No (defaults to the workspace root if not specified).

• Bamboo Variables: Supported.

• Examples:

• frontend (for a monorepo structure)

  • apps/web (for nested project structures)
  • Leave empty if package.json is in the workspace root.

Bamboo Variables

All text fields support Bamboo variable substitution for flexible configuration.

• Built-in Variables: Use variables like ${bamboo.build.working.directory} to reference standard Bamboo paths.

• Custom Variables: Define project-level or plan-level variables for environment-specific configuration.

• Example: Configure source patterns as ${bamboo.build.working.directory}/src/**/*.js to adapt to different workspace locations.

Using .NET Reachability Analysis on Bamboo DC

.NET reachability is supported in Sonatype for Bamboo Data Center 4.5.0 and later.

Use the options below to enable Reachability Analysis for your builds. Select Enable .NET reachability analysis; all the others are optional.

Entrypoint Strategy

Entrypoint strategy for .NET reachability analysis.

Running Reachability Analysis Across Multiple Ecosystems

The Sonatype for Bamboo Data Center plugin supports running reachability analysis for multiple ecosystems in a single build.

Enabling Multiple Ecosystems

To analyze multiple ecosystems in a single build:

1. Select the reachability analysis options for the ecosystems you want to analyze in the task configuration.

2. Configure language-specific parameters for each analysis type.

3. The selected analyses will run during the build, with results aggregated automatically.

Result Aggregation

When multiple reachability analyzers run:

• Combined Results: Reachable vulnerabilities from the selected reachability analyses are merged and reported together in the IQ Server evaluation.

• Independent Failures: If one analyzer fails, the other enabled analyzers continue, and partial results are still reported.

• Aggregated Counts: The final policy evaluation reflects the total count of reachable vulnerabilities across all analyzed ecosystems.