Reachability Analysis with Gitlab CI

Reachability Analysis with Gitlab CI

You can configure Sonatype for GitLab CI 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 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.
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:

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