Snyk for Java and Kotlin

Snyk offers security scanning to test your projects for vulnerabilities, both from the Snyk CLI and the Snyk Web UI using different Snyk Integrations.

Features of Snyk for Java and Kotlin

The following tables provide an outline of the general features Snyk offers by language. In addition to these features, Snyk offers additional functionality related to the specific integration configurations.
Some features might not be available, depending on your pricing plan. See pricing plans for more details.
Gradle projects imported via Git are tested by parsing build.gradle files. As the only truly reliable way to resolve Gradle dependencies is to execute the tool itself, this method can sometimes provide incomplete results.
If possible, enable lockfiles in your Gradle project to improve the accuracy for Git imports.
However, for the most accurate results, Snyk recommends using the Snyk CLI to test Gradle Projects.
Package managers / Features
CLI support
Git support
License scanning
Fix PRs
Fix advice only
Package managers / Features
CLI support
Git support
License scanning
Fix PRs
Fix advice only

Supported versions

Maven versions supported

Gradle versions supported

Gradle 8 is not yet supported in the CLI.
However, if your app does not use Gradle 8 specific features, it is generally possible to install Gradle 7 instead before running Snyk CLI scans

Snyk CLI for Java and Kotlin projects (CI/CD)

The way Snyk analyzes and builds the dependencies varies depending on the language and package manager of the Project.
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 analyzes the output of the pom.xml files.

CLI options for Java and Kotlin

This section describes the unique CLI commands available when working with Java-based Projects.

Prerequisites for Snyk CLI with Java and Kotlin

  • Install the relevant package manager before you use the Snyk CLI.
  • Include the relevant manifest files supported by Snyk before testing.
  • Install and authenticate the Snyk CLI to start analyzing Projects from your local environment. See Getting started with the CLI.

Snyk CLI options for Maven and Gradle

For information about the snyk test and snyk monitor options available for use with Maven and Gradle, see the following pages:

Scan unmanaged JAR files

If you're not using Maven or Gradle but have JAR files, you can identify the open source packages these relate to using Snyk CLI.

Examples of how you can use Maven arguments with the Snyk CLI

Test a specific Maven profile called “prod”.
snyk test -- -prod
Add a system property from your pom.xml file.
The package version appears in your pom.xml
Define the system property like this:
snyk test -- -Dpkg_version=1.4

CLI help for Maven Projects: Aggregate 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 resolvable 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 --all-projects option:
    snyk test --all-projects
The same options can be used with snyk monitor.
Make 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.

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 project, 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

Configurations for Gradle project

Gradle dependencies are declared for a particular scope; each scope is represented by Gradle with the help of Configurations. For example:
  • compileOnly configuration for development dependencies
  • compile configuration that includes compile and runtime dependencies
By default Snyk merges all configurations returned by Gradle to a dependency graph based on the sum total of the dependencies across all configurations in the Project or Projects.
To test a specific configuration:
  • Use the --configuration-matching option with a Java regular expression (case-insensitive) as its parameter. The configuration that matches is then tested. If several configurations match, they are all merged and resolved together. For example: '^releaseRuntimeClasspath$|^compile$'
  • 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:
  • 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 and org.gradle.usage=java-runtime


By default, Snyk passes gradle build --no-daemon in the background when running snyk test and snyk monitor on Windows. If for some reason 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.


If your Gradle project makes use of a single gradle.lockfile or multiple *.lockfile per configuration and you are having 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.
Note that that compileOnly configuration has been deprecated and even if your Project successfully generates a lockfile, it will not contain the `compileOnly` state because this configuration cannot be resolved. Only resolvable configurations compute a dependency graph. In order to solve this issue, Snyk suggests you update your build.gradle containing dependencyLocking logic with the following instruction:
compileOnly {resolutionStrategy.deactivateDependencyLocking() }
This will ignore compileOnly and save only the necessary information to analyze your Project of Projects.

Support for Gradle with Snyk

If you are having any trouble testing your Gradle projects with Snyk, collect the following details and send them to Snyk at [email protected]:
  • 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

Git services for Maven projects

After you select a project for import, Snyk builds the dependency tree based on the pom.xml file.

Git services for Gradle projects

After you select a project for import, Snyk builds the dependency tree based on the build.gradle file and (optional) gradle.lockfile.
Only dependencies in the following configurations are included - api, compile, classpath, implementation, runtime, runtimeOnly.
If a lockfile is present, Snyk uses the lockfile to more accurately resolve the final version of dependencies used in the Project.
Gradle lockfiles are an opt-in feature that, among other benefits, enable reproducible builds. For more information see the Gradle docs on dependency locking.
Kotlin: build.gradle.kts files are not currently supported in Git.

Git settings for Java

From the Snyk UI you can specify mirrors or repositories from which you’d like to resolve packages in Artifactory for Maven. For more information see Artifactory Registry for Maven.

Additional Snyk support for Java

In addition to the CLI and Snyk UI features, you can also check your Java Projects using Maven integration.