Skip to main content

Reachability Analysis with Sonatype CLI

You can configure Sonatype CLI 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 an additional parameter in the CLI command you can enable the Reachability Analysis feature. The scan process will then analyze your application and its dependency, based on the provided scan targets and reachability parameters. This allows you to detect reachable vulnerabilities, even in proprietary components within your application.

Permissions Required

Sonatype CLI users should have the Evaluate Applications permissions to scan applications with Reachability Analysis.

Using Java Reachability Analysis

Use the following CLI parameters to enable Java Reachability Analysis:

Parameter

Description

-ra, --reachability

Enable Reachability Analysis in Java or JVM language binaries to determine the method signatures that trigger a security vulnerability.

-rn, --reachability-namespaces

Limit Reachability Analysis to one or more namespaces for faster, more precise results. To specify multiple namespaces, repeat the parameter, e.g., -rn com.package1 -rn org.package2.

--res, --reachability-entrypoint-strategy

Entrypoint strategy for Java reachability analysis.

-c, --call-flow-analysis

Deprecated in version 2.4.0. Use -ra, --reachability instead.

-cn, --call-flow-analysis-namespaces

Deprecated in version 2.4.0. Use -rn, --reachability-namespaces instead.

Reachability Evidence

When Sonatype CLI 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.

Entrypoint Strategy

The entrypoint strategy determines which methods are treated as entry points for your application.

When Java Reachability Analysis is enabled, 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.

The default entrypoint strategy is CONCRETE. Use the --reachability-namespaces parameter (described above) to restrict the method set to specific namespaces (i.e. Java package names) and improve the overall results.

Using JavaScript Reachability Analysis

Use the following CLI parameters to enable JavaScript Reachability Analysis:

Parameter

Description

-rajs, --reachability-js

Enable Reachability Analysis for JavaScript and related languages projects.

-rjs, --reachability-js-sources

Ant-style patterns that match JavaScript source files to be considered for the reachability analysis. This is a required parameter for JavaScript reachability. Include here your main JavaScript application files. Do not include tests or any dependencies (e.g. files under node_modules). To specify multiple patterns repeat the parameter, e.g. -rjs src/** -rjs additional-src/**.

-rje, --reachability-js-excludes

Ant-style patterns that match JavaScript source files to be excluded from the reachability analysis. Include here test files and any other source files that are not relevant for the analysis. To specify multiple patterns repeat the parameter, e.g. -rje tests/** -rje integration-tests/**.

-rjr, --reachability-js-project-root

JavaScript project root directory (i.e. where the main package.json file resides). If not provided it defaults to the current working directory.

-rnp, --reachability-node-path

Full path to the Node.js executable, in case it is not already included in the system path.

Example

The following example assumes the application source files are located under the src directory. All tests reside in the tests directory, a Node.js executable is available in the system path, and the CLI is executed in the project’s root directory:

java -jar nexus-iq-cli*.jar \
  -s http://localhost:8070 -a username:password -i sandbox-application \
  -rajs -rjs src/** -rje tests/** \
  ./package-lock.json

Using .NET Reachability Analysis

.NET Reachability Analysis determines whether vulnerable methods in NuGet and .NET assembly (PE/COFF) dependencies are reachable from your application's code. Unlike Java and JavaScript reachability, .NET reachability is currently configured exclusively through CLI flags.

Prerequisites

  • .NET SDK 8.0 or later must be installed and the dotnet command must be available on the system PATH. If dotnet is in a non-standard location, use the -rdnp flag to specify the path.

  • The scan target should be a directory containing both the application DLL and its dependency DLLs (for example, the output of dotnet publish). Missing dependency DLLs may result in incomplete analysis.

CLI Parameters

Parameter

Description

-radn, --reachability-dotnet

Enable Reachability Analysis for .NET applications.

-rndn, --reachability-dotnet-namespaces

Limit analysis to one or more namespaces. Can be specified multiple times (e.g., -rndn MyApp.Controllers -rndn MyApp.Services). Supports prefix matching (default) or regex matching (enclose pattern in /, e.g., -rndn “/MyApp\\.(Controllers|Services)/ matches classes in either the MyApp.Controllers or MyApp.Services namespaces)

-resdn, --reachability-dotnet-entrypoint-strategy

Controls how entry points are identified. Defaults to CONCRETE. See Entrypoint Strategy below.

-rdnp, --reachability-dotnet-path

Path to the dotnet executable, if not on the system PATH.

-rr, --reachability-result

Path to write a local JSON file containing the reachability results.

.NET reachability (-radn) can be enabled alongside Java (-ra) and JavaScript (-rajs) reachability in the same scan. Each language is analyzed independently and results are merged before being sent to IQ Server.

Entrypoint Strategy

The entrypoint strategy determines which methods in the application are treated as starting points for call graph analysis.  

Strategy

Description

CONCRETE

(Default) All non-abstract, non-synthetic methods in non-interface classes.

PUBLIC_CONCRETE

Public, non-abstract, non-synthetic methods in non-interface classes. Recommended for web applications and library projects.

ACCESSIBLE_CONCRETE

Public or protected, non-abstract, non-synthetic methods in non-interface classes.

DOTNET_MAIN

Static methods matching one of the 8 standard .NET Mainsignatures (case-insensitive, supporting both C#/VB.NET Main and F# main). Does not match top-level statement entry points (C# 9+); use PUBLIC_CONCRETE or CONCRETE with namespace filtering for those projects.

  • static void Main()

  • static void Main(string[] args)

  • static int Main()

  • static int Main(string[] args)

  • static async Task Main()

  • static async Task Main(string[] args)

  • static async Task<int> Main()

  • static async Task<int> Main(string[] args)

ALL

All methods in non-interface classes, including abstract methods.

Note

JAVA_MAINis not valid for .NET reachability. The .NET equivalent is DOTNET_MAIN. If an invalid strategy is provided, the CLI logs a warning and falls back to CONCRETE.

Use the -rndn parameter to further narrow entry points to specific namespaces and improve precision.

Examples

Basic .NET Reachability Scan

java -jar nexus-iq-cli.jar \
  -i my-app \
  -s https://iq.example.com \
  -a admin:password \
  -t build \
  -radn \
  path/to/published/app

With Namespace Filtering

Restrict entry points to your application's namespaces to reduce noise and improve precision:

java -jar nexus-iq-cli.jar \
  -i my-app \
  -s https://iq.example.com \
  -a admin:password \
  -t build \
  -radn \
  -rndn MyApp.Controllers \
  -rndn MyApp.Services \
  path/to/published/app

With a Specific Entrypoint Strategy

Use DOTNET_MAIN for console applications with an explicit Main method:

java -jar nexus-iq-cli.jar \
  -i my-console-app \
  -s https://iq.example.com \
  -a admin:password \
  -t build \
  -radn \
  -resdn DOTNET_MAIN \
  path/to/published/app

Use PUBLIC_CONCRETE for web applications or library projects (where the framework invokes your code via public methods rather than a Main entry point):

java -jar nexus-iq-cli.jar \
  -i my-web-api \
  -s https://iq.example.com \
  -a admin:password \
  -t build \
  -radn \
  -resdn PUBLIC_CONCRETE \
  -rndn MyApp \
  path/to/published/app

With Local Results File

Save reachability results to a local JSON file for debugging or downstream tooling:

java -jar nexus-iq-cli.jar \
  -i my-app \
  -s https://iq.example.com \
  -a admin:password \
  -t build \
  -radn \
  -resdn PUBLIC_CONCRETE \
  -rndn MyApp \
  -rr reachability-results.json \
  path/to/published/app

With Custom dotnet Path

If the dotnet executable is not on PATH:

java -jar nexus-iq-cli.jar \
  -i my-app \
  -s https://iq.example.com \
  -a admin:password \
  -t build \
  -radn \
  -rdnp /usr/local/share/dotnet/dotnet \
  path/to/published/app

With Regex Namespace Filtering

Use regex patterns (enclosed in /) for complex namespace matching:

java -jar nexus-iq-cli.jar \
  -i my-app \
  -s https://iq.example.com \
  -a admin:password \
  -t build \
  -radn \
  -resdn PUBLIC_CONCRETE \
  -rndn "/MyApp\.(Controllers|Services|Handlers)/" \
  path/to/published/app