Reachability Analysis with Sonatype for Azure DevOps

You can configure Sonatype for Azure DevOps 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 pipeline tasks 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), JavaScript/TypeScript, and .NET projects. This allows you to detect reachable vulnerabilities, even in proprietary components within your application.

Permissions Required

Sonatype for Azure DevOps users should have the Evaluate Applications permissions to scan applications with Reachability Analysis.

Ignoring Reachability Analysis Errors

If this setting is checked, reachability execution failures do not impact the build status. Otherwise, the build is marked as FAILED.

Using Java Reachability Analysis

Both the Sonatype Evaluate task and the Sonatype for Azure DevOps task expose parameters to enable Java Reachability Analysis:

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

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

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/

• Java Reachability Entrypoint Strategy: When 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 same parameters can be used in a scripted pipeline, as in the example below:

- task: SonatypeEvaluate@2
  inputs:  # other input parameters could be provided here
    enableReachability: true
    reachabilityNamespaces: 'com.example.library.one com.example.app.two'
    reachabilityEntrypointStrategy: CONCRETE  # more input parameters may follow

Entrypoint Strategy

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

The default entrypoint strategy is CONCRETE, which means every non-abstract, non-synthetic method defined in a non-interface, non-annotation class is considered a potential entry point. Use the Java Reachability namespaces parameter (described above) to restrict the method set to specific namespaces and improve the overall results.

Using JavaScript Reachability Analysis

Both the Sonatype Evaluate task and the Sonatype for Azure DevOps task expose parameters to enable JavaScript Reachability Analysis.

• Enable JavaScript Reachability: Enable Reachability Analysis for JavaScript to determine the method signatures that trigger a security vulnerability.

• JavaScript Reachability Sources: JavaScript source file patterns for Reachability Analysis (REQUIRED when JavaScript reachability is enabled). Use comma or space-separated glob patterns. e.g. src/**/*.js src/**/*.ts

• JavaScript Reachability Excludes: JavaScript file patterns to exclude from Reachability Analysis. Use comma or space-separated glob patterns. e.g. node_modules/** test/**

• Node.js Executable Path: Custom path to Node.js executable for JavaScript Reachability Analysis. If not specified, the CLI will use the default Node.js in PATH.

• JavaScript Project Root: Root directory of the JavaScript project for reachability analysis (i.e. where the main package.json file resides). If not specified, the CLI will use the scan target directory.

The same parameters can be used in a scripted pipeline, as in the example below:

- task: SonatypeEvaluate@2
  inputs:
    applicationId: 'myapp'
    scanTargets: 'package-lock.json'
    enableReachabilityJs: true
    reachabilityJsSources: 'src/**/*.js'
    reachabilityJsExcludes: 'src/test/**/*.js'
    reachabilityJsProjectRoot: '.'

Using .NET Reachability Analysis

.NET reachability is supported in Sonatype for Azure DevOps 2.12.0 and later.

Both the Sonatype Evaluate task and the Sonatype for Azure DevOps task expose parameters to enable .NET Reachability Analysis.

• Enable .NET Reachability: Enables .NET reachability analysis for IQ policy evaluation. This will help you find vulnerable .NET code that is in use.

• .NET Reachability Namespaces: Namespace prefixes to scope entry points for .NET reachability analysis. Use space-separated values. e.g. MyCompany.App MyCompany.Core

• .NET Reachability Entrypoint Strategy: Entrypoint strategy for .NET reachability analysis.

• .NET Executable Path: Absolute path to dotnet executable. When not specified, assumes dotnet is available on the system PATH.

The same parameters can be used in a scripted pipeline, as in the example below:

- task: SonatypeEvaluate@2
  inputs:
    applicationId: 'myapp'
    scanTargets: '*.dll'
    enableReachabilityDotNet: true
    reachabilityDotNetNamespaces: MyCompany.App
    reachabilityDotNetEntrypointStrategy: 'DOTNET_MAIN'
    reachabilityDotNetPath: /opt/bin/dotnet

Search results

No results found.