Snyk CLI with Maven and Gradle

The Snyk CLI tests Maven and Gradle Projects as follows:

Snyk CLI with Gradle: To build the dependency graph, Snyk integrates with Gradle and inspects the dependencies returned by the build. The following manifest files are supported: build.gradle (Groovy DSL) and build.gradle.kts (Kotlin DSL).
Snyk CLI with Maven: To build the dependency tree, Snyk integrates with Gradle and inspects the dependencies returned by the build. The following manifest files are supported: pom.xml.

The following lists steps to start scanning your dependencies. It covers basic commands, such as snyk test and snyk monitor. To check the full list, see CLI commands and options summary.

Package manager

Test help

Monitor help

CLI help for Maven Projects

A Maven aggregate Project is one that uses modules and inheritance.

When scanning these types of Projects, Snyk performs a compile to ensure all modules are fixable by the Maven reactor.

To scan aggregate Projects, use the --maven-aggregate-project option:
```
snyk test --maven-aggregate-project
```
To scan non-aggregate Projects, use the --all-projects option:
```
snyk test --all-projects
```

The same options can be used with snyk monitor.

Be sure to execute the options in the same directory as the root pom.xml file.

Each of the individual sub-projects appears as a separate Snyk Project in the Web UI.

Examples of how to use Maven-specific options with the Snyk CLI

Test a specific Maven profile called “prod”.

snyk test -- -prod

Add a system property from your pom.xml file.

Example:

The package version appears in your pom.xml

${pkg_version}

Define the system property like this:

snyk test -- -Dpkg_version=1.4

CLI help for Gradle Projects

Gradle build can consist of several sub-projects, where each sub-project has its own build.gradle, while the root Project is the only one that also includes a settings.gradle file. Sub-projects depend on the root ProjectProjects but can be configured otherwise.

By default, Snyk CLI scans only the current Project, the Project in the root of the current folder, or the Project that is specified by --file=path/to/build.gradle).

To scan all Projects at once (recommended), use the --all-sub-projects option:
```
snyk test --all-sub-projects
```

Each of the individual sub-projects appears as a separate Snyk Project in the Web UI.

To scan a specific Project (for example, myapp):
```
snyk test --sub-project=myapp
```

Gradle configurations

Gradle dependencies are declared for a particular scope; each scope is represented by Gradle with the help of Configurations. For example:

implementation: configuration for dependencies required at compile time and runtime, but not exposed to consumers.
api: configuration for dependencies required at compile time and runtime, and exposed to consumers.
compileOnly: configuration for dependencies required only at compile time.
runtimeOnly: configuration for dependencies required only at runtime.
compileClasspath: configuration for dependencies required at compile time.

In most cases, Snyk will include all the dependencies in the compileClasspath configuration, but this can vary in some circumstances.

To test a specific configuration:

Use the --configuration-matching option with a Java regular expression (case-insensitive) as its parameter. Note that only the first configuration that matches is tested.
If the different sub-projects include different configurations, scan each sub-project separately.

Examples of how you can use the --configuration-matching option

--configuration-matching=compile will match compile, testCompile, compileOnly, and so on.
--configuration-matching=^compile$ will match only compile.
--configuration-matching='^(debug|release)compile$' will match debugCompile and releaseCompile.
--configuration-matching='^(?!.*test).*$' will match all configurations except those containing the string "test".

Android build variants

Android Gradle supports creating different versions of your app by configuring build variants.

Because the Snyk default behavior is to merge all available configurations, the iterated variants cause a clash of configurations that can't be merged.

In these situations, the Snyk scan fails with an error from Gradle which may contain one of the following messages:

Cannot choose between the following configurations of project :mymodulewithvariants
Cannot choose between the following variants of project :mymodulewithvariants
Could not select value from candidates

To avoid such conflicts:

Use a specific configuration(s): if you know of a build configuration that has all the required attributes and the configuration is identical across all sub-projects included in the test, specify that configuration. For example:
```
--configuration-matching=prodReleaseRuntimeClasspath
```
Explicitly specify the dependency configuration: modify intra-project dependencies in your build.gradle file(s) to use a specific configuration
```
  dependencies {
      implementation project(path: ':mymodulewithvariants', configuration: 'default')
  }
```
Suggest configuration attributes: if you receive an error when running the command, the error may indicate which attribute values are available, while the error details from Gradle also indicate which dependency variants match which attributes. Using these details, add the attribute filter option. For example:
```
snyk test --configuration-attributes=buildtype:release,usage:java-runtime,mode:demo
```
matches the variants using com.android.build.api.attributes.BuildTypeAttr=release and org.gradle.usage=java-runtime

Daemon

By default, Snyk passes gradle build --no-daemon in the background when running snyk test and snyk monitor on Windows.

If you see snyk test or snyk monitor fail on other operating systems because of daemon-related issues, try adding the --no-daemon flag to the Snyk command or set GRADLE_OPTS: '-Dorg.gradle.daemon=false'.

See the Gradle documentation for tips on disabling the daemon.

Lockfiles

If your Gradle Project makes use of a single gradle.lockfile or multiple *.lockfile per configuration, you may see the following issue:

Gradle Error (short): > Could not resolve all dependencies for configuration ':compileOnly'. > Locking strict mode: Configuration ':compileOnly' is locked but does not have lock state.

The compileOnly configuration has been deprecated, and even if your Project successfully generates a lockfile, the compileOnly state is not included because this configuration cannot be resolved.

Only resolvable configurations compute a dependency graph. To solve this issue, Snyk suggests you update your build.gradle containing dependencyLocking logic with the following instruction:

compileOnly {resolutionStrategy.deactivateDependencyLocking() }

This ignores the compileOnly and saves only the necessary information to analyze your Project.

Getting help

If you are having any trouble testing your Gradle Projects with Snyk, collect the following details and send them to Snyk at support@snyk.io:

build.gradle
settings.gradle (especially if Snyk did not pick up a version of a package)
The output from the following commands:
- $ snyk test -d
- $ gradle dependencies -q

PreviousJava and Kotlin for open source NextGit repositories with Maven and Gradle

Last updated 1 month ago