# Reachability Analysis with Sonatype for Azure DevOps

You can configure Sonatype for Azure DevOps to perform [Reachability Analysis](https://help.sonatype.com/en/reachability-analysis.html "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.