Snyk CLI for Java and Kotlin

To test Maven and Gradle Projects, use the snyk test command 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.

Package manager-environment	Test help	Monitor help
Maven	--maven-aggregate-project Options for Maven Projects. Example for aggregate projects: snyk test --maven-aggregate-project Ensure you execute the options in the same directory as the root pom.xml file.	--maven-aggregate-project Options for Maven Projects. Example for aggregate projects: snyk monitor --maven-aggregate-project Ensure you execute the options in the same directory as the root pom.xml file.
Gradle	--init-script=<FILE> - Used for projects with a Gradle initialization script. Options for Gradle Projects.	--init-script=<FILE> - Used for projects with a Gradle initialization script. Options for Gradle Projects.
Build tools	snyk test -- [<context-specific_options>] See Options for build tools.
Unmanaged JAR files	--scan-unmanaged - Tests unmanaged files --scan-unmanaged --file=<JAR_FILE_NAME> - Tests individual JAR, WAR, and AAR files --scan-all-unmanaged - Auto-detects Maven, JAR, WAR, and AAR files recursively from the current folder. See Options for unmanaged JAR files.	--scan-unmanaged - Tests unmanagedfiles --scan-unmanaged --file=<JAR_FILE_NAME> - Testsindividual JAR, WAR, and AAR files --scan-all-unmanaged - Auto-detects Maven, JAR, WAR, and AAR files recursively from the current folder. See Options for unmanaged JAR files.

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

You can use the same options with snyk monitor.

The following example outlines how Maven-specific options are used with the Snyk CLI.

1. Test a specific Maven profile called “prod”.

snyk test -- -prod

1. Add a system property from your pom.xml file, for example, the package version that appears in your pom.xml:

${pkg_version}

1. Define the system property:

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 eb UI.

To scan a specific Project (for example, "myapp"), use the following command:

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 includes 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. The CLI identifies all resolvable configurations that match the regex and aggregates their dependencies into a single scan result. If you require separate reports for different configurations (for example, compile vs. runtime), run the command separately for each.

• 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 to match compile, testCompile, compileOnly, and so on.

• --configuration-matching=^compile$ to match only compile.

• --configuration-matching='^(debug|release)compile$' to match debugCompile and releaseCompile.

• --configuration-matching='^(?!test).*$' to match all configurations except those starting with "test" (for example, excludes testCompileClasspath, testRuntimeClasspath). This is recommended for with large dependency graphs that hit max path limits, as excluding test configurations reduces the graph size while still covering production dependencies.

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 can 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'.

For tips on disabling the daemon, the Gradle documentation.

Lockfiles

If your Gradle Project uses a single gradle.lockfile or multiple *.lockfile per configuration, the following issue can appear:

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.

If you have trouble testing your Gradle Projects with Snyk, contact Snyk support and provide the following details:

• 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

Snyk CLI tips and tricks

the CLI commands and options summary and the CLI cheat sheet. Use the --help option in the CLI for details of Snyk CLI commands.

Testing your own code

• Use the snyk code test command from the root of the project to perform source code analysis.

• Use --scan-all-unmanaged --all-projects to recursively find all jars under the present working directory.

Testing Open Source libraries

Maven

The snyk test command tests the first manifest it can find, and scans that singular entry point. To scan all manifests, follow these instructions:

• To scan aggregate projects, use the --maven-aggregate-project option (for example, snyk test --maven-aggregate-project)

• To scan for all projects use --all-projects option: (that is, snyk test --all-projects)

Snyk scans active profiles activated by default.

• Any additional Maven arguments can be passed, a common one is a non-standard settings.xml location. For example, snyk test -- -s path/to/settings.xml

• To scan a specific configuration, test a specific Maven profile using -P [name]. For example, use snyk test -- -P prod to scan the prod configuration.

Gradle

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.

--all-projects can be used across all package managers, which also includes the behaviors of --all-sub-projects, mentioned below.

• To scan all projects at once (recommended), use the --all-sub-projects option: (that is, snyk test --all-sub-projects). Each of the individual sub-projects appears as a separate Snyk Project in the eb UI.

• To scan a specific project (for example, myapp), use --sub-project= (that is, snyk test --sub-project=myapp).

specific configurations, Snyk for Java and Kotlin.

Unmanaged

For more details on unmanaged Jars, Scan all unmanaged JAR files.

Testing containers

Snyk automatically looks for application (such as open source, maven, and npm) vulnerabilities as part of a container scan. Snyk recommends integrating via CLI or Registry earlier in the pipeline and use this as an additional signal or insight into what is in production. Snyk CLI for container security.

To test Infrastructure as Code, Infrastructure as Code security.

To fix vulnerabilities, Fixing vulnerabilities on Maven projects.

Options and plugins

To help generate reports locally or at build time, snyk-to-html plugin.

See --json and --sarif options for generating output that can be programmatically accessed.

For advanced filtering options, snyk-filter.