Java and Kotlin

Supported frameworks and package managers

Code analysis

Snyk Code for Kotlin

Android is partially supported.

Interfile is supported, as the data flow is monitored between multiple files.

Snyk Code supports the following frameworks:

  • Apache Camel

  • Apache Struts

  • Dropwizard

  • Jakarta XML Services

  • Java Servlet

  • JSP

  • Spring Boot (partial support)

  • Spring MVC

  • Spring JDBC

Open source and licensing

Snyk Open Source provides full support for Java and Kotlin, as outlined below.

Some features might not be available, depending on your pricing plan. See pricing plans for details.

Gradle Projects imported via Git are tested by parsing build.gradle files. You can resolve Gradle dependencies only by executing the tool itself, but even this method can sometimes provide incomplete results.

If possible, enable lockfiles in your Gradle Project to improve the accuracy of Git imports.

For Gradle projects without lockfiles, Snyk recommends using the Snyk CLI for the most accurate results.

Java

Package managers / FeaturesCLI supportGit supportLicense scanningFix PRs

✔︎

✔︎

✔︎

✔︎

✔︎

✔︎

✔︎

Fix advice only

Supported versions of Maven and Gradle

MavenGradle

CLI - Maven 3.* For details, see the Snyk Maven plugin readme.

CLI - Gradle 4.*, 5.*, 6.*, 7.*, 8.* For more information, see the Snyk Gradle plugin readme.

Git - Maven 3.*

Git - Gradle 4.*, 5.*, 6.*, 7.*, 8.*

Open source policy

To manage licenses from your developer workflows through policy, see the following topics:

Open source license compliance

To check compliance for open source licenses, see Getting Started with Snyk License Compliance Management.

Getting started with Snyk for Java across environments

Snyk CLI

Prerequisites

  1. Install the relevant package manager before you use the Snyk CLI.

  2. Include the relevant manifest files supported by Snyk before testing.

Code analysis

To start testing your code using Snyk Code open your repository in a terminal and run the following command:

snyk code test

To customize test options, run other commands, exclude directories and files, and explore the results in different formats, see the following:

Open source and licensing

The following table lists the 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.

To scan your dependencies, ensure you install the relevant package manager and that your Project contains the supported manifest files.

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:

Package managerTest helpMonitor help

Maven

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 only configuration(s) that match 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.

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

--configuration-attributes=[,]... - Select certain values of configuration attributes to install dependencies and perform dependency resolution.

Build tools

Unmanaged JAR files

--scan-unmanaged - Test unmanager files

--scan-unmanaged --file=<JAR_FILE_NAME> - Test individual JAR, WAR, and AAR files

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

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

Examples of how to 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.

Example:

The package version appears in your pom.xml

${pkg_version}

Define the system property like this:

snyk test -- -Dpkg_version=1.4

Examples of how to use Gradle arguments with the Snyk CLI

  • 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

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.

CLI help for Gradle Projects

Sub-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

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:

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

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.

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

Git services for Maven and Gradle

The following table includes the Git services available for Maven and Gradle Projects.

Maven ProjectsGradle ProjectsGradle.lockfile

Gradle lockfiles do not contain transitive hierarchy information, so in some cases Snyk may place a package at the wrong position in the dependency graph. However no packages should be missing.

  • Using Maven, or Gradle with a gradle.lockfile:

    The Git code repository integration is a great way to use Snyk and get visibility or you may decide to use CLI/IDE or CI/CD integrations to test/gate/monitor, or do both!

  • Using Gradle without a Gradle.lockfile:

    The full dependency tree may not be apparent or artifacts may be pulled in from external resources, so the CLI/IDE workflow (for local scans), and CI/CD is the recommended approach for analysis, otherwise you may not have a complete view of issues and dependencies.

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.

The following table includes the Git services available for Maven and Gradle Projects.

Snyk Web UI (Git repository integration)

You can import Java repositories from any Git services (Source Control Managers) Snyk supports (see Git repositories). After the import, Snyk analyzes your Projects based on their supported manifest files.

How Snyk works for open source and licensing

Import Project

To import Projects from a Git repository integration:

  1. Open Snyk Web UI and go to your Group and Organization.

  2. Go to Projects.

  3. Click Add Projects, select the import source, and choose the repository. If you have an integrated Git repository (GitHub) it shows up as an option to choose from.

Import a Project

Configure language settings for open source

Configure language settings for your open source and licensing at the Organization level. The configuration settings apply to all Projects in that Organization.

  1. Open Snyk Web UI and go to Settings > Languages section.

  2. Under Languages, go to Java and select Edit settings.

  3. Configure the settings for Maven.

Setup your Nexus Repository Manager for Maven

  1. Update Settings to save changes.

The Snyk team has built plugins to make it easy to integrate Snyk into your workflows:

Validating, Monitoring, Alerting, and Gating

The following capabilities are available for all Snyk users:

With Git integrations

Snyk allows you to run PR Checks to validate submitted changes to code and open source packages before merging. Snyk can also retest and alert on the default branch on a scheduled basis, and show results.

These results are viewable on the Snyk projects screen, for:

  • Your code with Snyk Code

  • Open Source with Snyk Open Source