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 reported by the tool. 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 Maven and inspects the dependencies reported by the tool. The following manifest files are supported: pom.xml.

This page provides details and also provides a workaround for ant and ivy.

The following table lists options to start scanning your dependencies. It covers the snyk test and snyk monitor commands. For a list of all the options for these commands, see the CLI commands and options summary.

Package manager	Test help	Monitor help
Maven	--maven-aggregate-project ℹ️ See the Options for Maven Projects page for more details. Example for aggregate projects: snyk test --maven-aggregate-project Example for non-aggregate projects: snyk test --all-projects ℹ️ Be sure to execute the options in the same directory as the root pom.xml file.	--maven-aggregate-project ℹ️ See the Options for Maven Projects page for more details. Example for aggregate projects: snyk monitor --maven-aggregate-project Example for non-aggregate projects: snyk monitor --all-projects ℹ️ Be sure to execute the options in the same directory as the root pom.xml file.
Gradle	--sub-project=<NAME>, --gradle-sub-project=<NAME> - Test a specific Gradle sub-project. --all-sub-projects - Test all Gradle sub-projects. --all-projects - Test all Gradle projects. --configuration-matching=<CONFIGURATION_REGEX> - Resolve dependencies using the first configuration that matches the specified Java regular expression. --configuration-attributes=<ATTRIBUTE>[,<ATTRIBUTE>]...- Select certain values of configuration attributes to install and resolve dependencies. --init-script=<FILE> - Used for projects with a Gradle initialization script. ℹ️ See the Options for Gradle Projects page for more details.	--sub-project=<NAME>, --gradle-sub-project=<NAME> - Monitor a specific Gradle sub-project. --all-sub-projects - Monitor all Gradle sub-projects. --all-projects - Monitor all Gradle projects. --configuration-matching=<CONFIGURATION_REGEX> - Resolve dependencies using the first configuration that matches the specified Java regular expression. --configuration-attributes=[,]... - Select certain values of configuration attributes to install dependencies and perform dependency resolution. --init-script=<FILE> - Used for projects with a Gradle initialization script. ℹ️ See the Options for Gradle Projects page for more details.
Build tools	snyk test -- [<context-specific_options>] ℹ️ See the Options for build tools page for more details.	snyk monitor -- [<context-specific_options>] ℹ️ See the Options for build tools page for more details.
Unmanaged JAR files	--scan-unmanaged - Test unmanager files --scan-unmanaged --file=<JAR_FILE_NAME> - Test individual JAR, WAR, and AAR files --scan-all-unmanaged - Auto-detect Maven, JAR, WAR, and AAR files recursively from the current folder. ℹ️ See the Options for unmanaged JAR files page for more details.	--sub-project=<NAME>, --gradle-sub-project=<NAME> - Monitor a specific Gradle sub-project. --all-sub-projects - Monitor all Gradle sub-projects. --all-projects - Monitor all Gradle projects. --configuration-matching=<CONFIGURATION_REGEX> - Resolve dependencies using only configuration(s) that match the specified Java regular expression. --init-script=<FILE> - Used for projects with a Gradle initialization script. ℹ️ See the Options for unmanaged JAR files page for more details.

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 [e-mail]:

• 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

Workaround for ant and ivy

Apache Ant is a Java build system focused solely on executing build tasks defined in XML. Apache Ivy extends Ant by adding dependency management, handling library retrieval and transitive dependencies, which Ant alone does not manage.

Ivy dependencies are configured in an XML file, for example ivy.xml:

<ivy-module version="2.0">
    <info organisation="com.example" module="my-project" revision="1.0"/>

    <dependencies>
        <dependency org="junit" name="junit" rev="4.12" conf="default"/>
    </dependencies>
</ivy-module>

Such a dependency file is typically evaluated using an ant task defined in build.xml:

<target name="resolve-dependencies" depends="init">
    <ivy:retrieve pattern="${lib.dir}/[artifact]-[revision].[ext]"/>
</target>

Using the command ant resolve-dependencies, dependencies will be downloaded from Maven Central, just like regular Maven dependencies.

To let Snyk know about the dependency tree, you must first convert to the Maven POM format. Start by configuring a new makepom task in build.xml

<target name="makepom" depends="resolve-dependencies">
    <ivy:makepom ivyfile="${basedir}/ivy.xml" pomfile="${basedir}/pom.xml" conf="default,runtime">
        <mapping conf="default" scope="compile"/>
        <mapping conf="runtime" scope="runtime"/>
    </ivy:makepom>
</target>

With this, you can now run the following commands:

ant makepom
snyk test --file=pom.xml

The pom.xml file does not need to be checked in and can be deleted after a test is done using snyk. Additionally, the dependency tree can be monitored using:

snyk monitor --file=pom.xml