Reachability Analysis

As applications grow in size and complexity, so does the potential for vulnerabilities. The attack surface also expands with increased reliance on open-source software components. Given tight deadlines and competing priorities, it is often impractical to remediate every vulnerability. A pragmatic way to approach a near-zero risk state in a limited timeframe is to target the open-source software vulnerabilities that lie along the execution paths of an application i.e. are reachable.

Reachability Analysis allows you to identify these exposed components. When integrated into application scans, this analysis can detect which vulnerable components are accessible, labeling any associated policy violations as "Reachable" in the application report. The remediation efforts can then be targeted towards these "Reachable" policy violations.

Reachability Analysis supports Java (or any JVM language) binaries, JavaScript/Node.js projects, and .NET applications (NuGet and PE/COFF formats). Support for .NET applications is available as of IQ 203.

When enabled during application scans, it examines both the application binaries and their dependency binaries in the scan target folder. Reachability Analysis is available for all supported CI/CD integrations.

How does Reachability Analysis Work?

If a vulnerable component is detected and the application code calls a specific method in that component which could be exploitable, the policy violation is labeled as "Reachable".

If a vulnerable component is found but the application code does not execute any calls to the vulnerable method, the policy violation is labeled as "Not Reachable".

Example

Consider an XML reader application that has a dependency on com.vulnerables.utils: vulnerable-deserializer:1.5. It has an endpoint that receives an XML file. The endpoint code reads the content of the XML file using the method XMLReader.readFile() and renders it on-screen. Based on our security data, the method readfile() has known vulnerabilities and public CVEs .

Reachability analyzes the .jar files created by the build tool and scans the method signatures to identify the vulnerable methods that are reachable. The policy violation for the component com.vulnerables.utils: vulnerable-deserializer:1.5 is labeled as "Reachable." This will be displayed in the policy evaluation report for the corresponding scan and on the Violations Dashboard.

The XML reader application also has a feature that allows users to write the XML input to a LaTeX document and export it. One of the methods of the LaTeX library is vulnerable to remote command execution. Due to its known vulnerability, this method is never called and so is not in the execution path. Reachability Analysis will notlabel the policy violation as "Reachable."

Reachability Analysis is available for application‑artifact scans (for example, JAR, WAR, or compiled class directories). It is not currently supported for container targets (for example, container:alpine:3.4).

To learn how to run Reachability Analysis against application artifacts, see the Sonatype Integrations Supporting Reachability Analysis section.

Unknown (“-”) reachability status

In some cases, the Priorities view shows a reachability status of “-” (Unknown). This indicates that Reachability Analysis was not performed for the component or policy violation.

Common reasons include:

The component has no known security vulnerabilities (no CVEs).
The component is not a supported type for Reachability Analysis (currently Java/JVM, JavaScript, and .NET/NuGet).
The component could not be identified by IQ Server.
The component is excluded from analysis (for example, outside the namespaces configured for Reachability Analysis).
The dependency artifact is not present in the scan target.
The vulnerability cannot be mapped to a callable method.

Note

For best practices on namespace configuration and its impact on Reachability Evidence, see Reachability Evidence.

Reachability Evidence

Reachability Evidence is currently available for Java (JVM) scans only. JavaScript and .NET reachability evidence are not yet supported.

When an application scan identifies reachable vulnerabilities, Sonatype Lifecycle displays a Reachability Evidence accordion in the violation details view, directly below the Reachability Analysis status badge. This accordion shows compressed call paths from your application's entry points to each vulnerable method, helping you understand how a vulnerability is reachable and prioritize remediation accordingly.

Reading the Call Paths

Each path is displayed as a stacktrace-style trace. The following conventions apply:

Display element	Meaning
Component section (thin border)	Consecutive frames from the same JAR or component.
Tooltip on a method frame	Package URL (PURL) of the component, or the file path if the component is unknown.
...	Intra-component gap. One or more frames within the same JAR are omitted for readability.
... N more components ...	Cross-component elision. Intermediate components between displayed sections are omitted.
Showing N paths (additional paths not shown)	The total number of reachable paths exceeds the configured maximum, so only the first N paths are displayed.

Getting the Most from Reachability Evidence

For best results, include the -rn (--reachability-namespaces) flag when scanning. Without it, every method in the application is treated as an entry point, which can make call paths very long and noisy. Restricting analysis to your application's namespace keeps paths focused on code you own.

Example:

java -jar nexus-iq-cli*.jar \
  -s http://localhost:8070 -a username:password \
  -i my-application \
  -ra -rn com.mycompany.myapp \
  ./target/my-app.jar

When the Evidence Accordion Does Not Appear

The Reachability Evidence accordion is shown only when the scanned vulnerability has reachable call paths. It does not appear for:

Vulnerabilities labeled Not Reachable.
Scans where Reachability Analysis was not enabled.
Firewall or SBOM Manager violation views. Reachability Evidence is available only in scan-based Sonatype Lifecycle results.

System Properties (Self-hosted Only)

Administrators can tune Reachability Evidence behavior using the following Java system properties:

Property	Default	Description
`sonatype.reachability.evidence.enabled`	true	Kill switch. Set to `false` to disable evidence generation globally.
`sonatype.reachability.evidence.maxPaths`	10	Maximum number of call paths shown per vulnerability.
`sonatype.reachability.evidence.componentDepth`	6	Maximum number of component sections rendered in a single path.

Sonatype Integrations Supporting Reachability Analysis

Reachability Analysis is currently supported on all Sonatype CI integrations. To learn more about this feature, go to the Reachability Analysis page for the specific integration:

IQ Server and CLI compatibility

Reachability Analysis requires compatible versions of both IQ Server and IQ CLI.

Upgrading IQ CLI without upgrading IQ Server is not sufficient to enable Reachability Analysis. Customers must ensure that their IQ Server version supports reachability data ingestion and processing for the selected integration.

License Requirements

Reachability analysis requires the Call Flow Analysis license feature, which is included in most Lifecycle and Firewall product tiers.