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 |
|---|---|
| Enable Reachability Analysis in Java or JVM language binaries to determine the method signatures that trigger a security vulnerability. |
| Limit Reachability Analysis to one or more namespaces for faster, more precise results. |
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 followCI/CD Pipelines
Using Java Reachability Analysis
Use the following parameters with the /sonatype/evaluate pipeline step to enable Java Reachability Analysis.
Parameter | Description |
|---|---|
| Enable Reachability Analysis in Java or JVM language binaries to determine the method signatures that trigger a security vulnerability. |
| Limit Reachability Analysis to one or more namespaces for faster, more precise results. To specify multiple namespaces, repeat the parameter, e.g., |
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 reachability-analysis-namespaces parameter (described above) to restrict the method set to specific namespaces and improve the overall results.