# Reachability Analysis with Gitlab CI

You can configure Sonatype for GitLab CI 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 GitLab CI integration steps you can enable the Reachability Analysis feature. The scan process will then analyze all application and dependency Java (or any JVM language) binaries located in the scan target. This allows you to detect reachable vulnerabilities, even in proprietary components within your application.

## Permissions Required

Sonatype for GitLab CI users should have the _Evaluate Applications_ permissions to scan applications with Reachability Analysis.

## CI Components

### Using Java Reachability Analysis

Use the following parameters with the `evaluate` component to enable Java Reachability Analysis.

| Parameter | Description |
| --- | --- |
| `reachability-analysis` | Enable Reachability Analysis in Java or JVM language binaries to determine the method signatures that trigger a security vulnerability. |
| `reachability-analysis-namespaces` | Limit Reachability Analysis to one or more namespaces for faster, more precise results.<br>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$/` |
| `reachability-entrypoint-strategy` | Entrypoint strategy for Java reachability analysis (see next section). |
| `callflow-analysis` | Deprecated. Use `reachability-analysis` instead. |
| `callflow-analysis-namespaces` | Deprecated. Use `reachability-analysis-namespaces` instead. |

#### Usage Example

```
include:
  - component: "${CI_SERVER_FQDN}/sonatype-integrations/components/evaluate@main"
    inputs:
      # other input parameters could be provided here
      reachability-analysis: true
      reachability-analysis-namespaces:
        - com.package1
        - org.package2
      # more input parameters may follow
```

### Using JavaScript Reachability Analysis

Use the following parameters with the `evaluate` component to enable JavaScript Reachability Analysis.

| Parameter | Description |
| --- | --- |
| `reachability-analysis-js` | Enable Reachability Analysis for JavaScript projects and other related languages. |
| `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`). You can specify multiple patterns (array type field). |
| `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. You can specify multiple patterns (array type field). |
| `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. |

## CI/CD Pipelines

### Using Java Reachability Analysis

Use the following parameters with the `/sonatype/evaluate` pipeline step to enable Java Reachability Analysis.

| Parameter | Description |
| --- | --- |
| `-ra, --reachability-analysis` | Enable Reachability Analysis in Java or JVM language binaries to determine the method signatures that trigger a security vulnerability. |
| `-ran, --reachability-analysis-namespaces` | Limit Reachability Analysis to one or more namespaces for faster, more precise results. To specify multiple namespaces, repeat the parameter, e.g., `-ran com.package1 -ran org.package2`. |
| `-res, --reachability-entrypoint-strategy` | Entrypoint strategy for Java reachability analysis (see next section). |
| `-c, --callflow-analysis` | Deprecated. Use `reachability-analysis` instead. |
| `-cn, --callflow-analysis-namespaces` | Deprecated. Use `reachability-analysis-namespaces` instead. |

#### Entrypoint Strategy

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-analysis-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 parameters with the `/sonatype/evaluate` pipeline step to enable JavaScript Reachability Analysis.

| Parameter | Description |
| --- | --- |
| `-rajs, --reachability-analysis-js` | Enable Reachability Analysis for JavaScript projects and other related languages. |
| `-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`). You can specify multiple patterns (array type field). |
| `-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. You can specify multiple patterns (array type field). |
| `-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. |

### Using .NET Reachability Analysis

.NET reachability is supported in Sonatype for GitLab CI 2.11.0 and later.

Use the following parameters with the `/sonatype/evaluate` pipeline step to enable .NET Reachability Analysis.

| Parameter | Description |
| --- | --- |
| `-radn,--reachability-dotnet` | Enable .NET reachability analysis (Default: false) |
| `-rndn,--reachability-dotnet-namespaces` | Namespace prefixes to scope entry points for .NET reachability analysis |
| `-resdn,--reachability-dotnet-entrypoint-strategy` | Entrypoint strategy for .NET reachability analysis |

#### Entrypoint Strategy

| Strategy | Description |
| --- | --- |
| `CONCRETE` | (Default) All non-abstract, non-synthetic methods in non-interface classes. |
| `PUBLIC_CONCRETE` | Public, non-abstract, non-synthetic methods. 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 the standard .NET Main signatures (C#, VB.NET, F#). Does not match C# 9+ top-level statement entry points; use `PUBLIC_CONCRETE` with namespace filtering for those projects. |
| `ALL` | All methods in non-interface classes, including abstract methods |