Skip to main content

Reachability Analysis with Sonatype for GitHub Actions

You can configure Sonatype for GitHub Actions 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 workflow actions 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 GitHub Actions users should have the Evaluate Applications permissions to scan applications with Reachability Analysis.

Using Java Reachability Analysis

Both the Sonatype Evaluate action and the Sonatype Run CLI action expose two parameters to enable Java Reachability Analysis.

Parameter

Description

enable-reachability

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

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. Default: empty.

Usage Example

name: Sonatype Workflow
on: push
jobs:
  sonatype-evaluation:
    runs-on: ubuntu-latest
    steps:
      # some steps are omitted...
      - name: Run evaluate action
        uses: sonatype/actions/evaluate@v1
        with:
          # other input parameters could be provided here
          enable-reachability: true
          reachability-namespaces: 'com.example.library.one com.example.app.two'
          # 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 reachability-namespaces parameter (described above) to restrict the method set to specific namespaces and improve the overall results.