New Features
  1. Docs Library | Snyk
  2. Snyk Open Source
  3. Language & package manager support

Articles in this section

Snyk for Java (Gradle, Maven)

Snyk offers security scanning to test your projects for vulnerabilities, both through your CLI and through different integrations from our UI.

The following describes how to use Snyk to scan your Java projects:

Features

The following table provides a general outline of the general features we offer by language. In addition to these features, we also offer additional functionality related to the specific integrations you configure, and more.

Note

Features might not be available, depending on your subscription plan. 

Package
managers /
Features 

CLI support 

Git support 

License scanning 

Remediation 

Runtime monitoring 

Maven

✔︎

✔︎

✔︎

✔︎

✔︎

Gradle

✔︎

✔︎

✔︎

✔︎ (advice)

  
 

Snyk Supported Java versions & OS

Please refer to the following documentation for officially supported Java versions, operating systems and Node.js versions.

Snyk CLI tool for Java projects (CI/CD)

The way by which Snyk analyzes and builds the dependencies varies depending on the language and package manager of the project.

Learn how to use the tool for your Java projects as follows:

 

How Snyk CLI works with Gradle

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

  • build.gradle.kts

 
How Snyk CLI works with Maven

In order to build the dependency tree, Snyk analyzes the output of the  the pom.xml files.

 
CLI parameters for Java

This section describes the unique CLI commands available when working with Java-based projects as follows:

 

Prerequisites

  • Ensure you've installed the relevant package manager before you begin using the Snyk CLI tool.

  • Ensure you've included the relevant manifest files supported by Snyk before testing.

  • Install and authenticate the Snyk CLI to start analyzing projects from your local environment. Read more about our CLI in Getting started with the CLI.

 
Snyk CLI for Gradle (CI/CD)

This section describes:

Snyk CLI parameters

When working with Gradle projects from our CLI, you can add any of the following options to further refine the way the scan works:

Option

Description

--sub-project=<string>

For Gradle "multi-project" configurations, test a specific sub-project.

--all-sub-projects 

For "multi-project" configurations, test all sub-projects.

--configuration-matching=<string>

Resolve dependencies using only configuration(s) that match the provided Java regular expression. 

For example:

'^releaseRuntimeClasspath$'

--configuration-attributes=<string>

Select certain values of configuration attributes to resolve the dependencies. 

For example: 'buildtype:release,usage:java-runtime'

--all-projects

Use for monorepos. This will detect all supported manifests. For Gradle monorepos Snyk will only look for root level build.gradle / build.gradle.kts files and apply the same logic as --all-sub-projects behind the scenes. This command is designed to be run in the root of your monorepo.

 

Gradle 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 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 flag: 
    snyk test --all-sub-projects 
    Note: Each of the individual sub-projects appears as a separate Snyk project in the UI.
  • To scan a specific project (for example, myapp): 
    snyk test --sub-project=myapp 

 
Configurations

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 dependency graph based on the sum total of the dependencies across all configurations in the project/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. E.g.'^releaseRuntimeClasspath$|^compile$'

  • If the different sub-projects include different configurations, scan each sub-project separately.

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

  • --configuration-matching=compile will match compile, testCompile, compileOnly etc;

  • --configuration-matching=^compile$ will match only compile;

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

 
Gradle Android build variants

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

Since Snyk defaults to merging all available configurations the variants will result in a clash of un-mergeable configurations.

In such cases, 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 
Pass extra arguments directly to Gradle or Maven via Snyk CLI

You can pass any extra Gradle or Maven arguments directly to gradle or mvn by providing them after a Snyk command like so:

snyk test -- --build-cache 

 

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. 

For example:

The package version appears in your pom.xml

<version>${pkg_version}</version>

Define the system property like this:

snyk test -- -Dpkg_version=1.4
 
Gradle daemon

By default, Snyk passes gradle build --no-daemon in the background when running snyk test and snyk monitor. If for any reason, you run into trouble, try this:

  1. Start the Gradle daemon.

  2. Add --daemon to your snyk test or snyk monitor.

If the problem persists, contact us for additional assistance with the details as outlined here.

 
Support

If you are having any trouble testing your projects with Snyk, collect the following details and send them to us at so we can help you out:

  • build.gradle

  • settings.gradle (especially if we did not pick up a version of a package)

  • The output from the following commands:

    • $ snyk test -d

    • $ gradle dependencies -q

Git services for Gradle projects

Once you select a project for import, we build the dependency tree based on the build.gradle file and (optional) gradle.lockfile.

If a lockfile is present, Snyk will use it to 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.  Read more about Gradle dependency locking at https://docs.gradle.org/current/userguide/dependency_locking.html

 

Git services for Maven projects

Once you select a project for import, we build the dependency tree based on the pom.xml file. 

A Java project can target multiple target frameworks. Snyk creates a separate dependency tree for each target framework, displaying each as a separate Snyk project from the interface. In this way, it’s easier to understand why a dependency is being used and also to asses the fix strategy. 

image1.png
Git settings for Java

From the Snyk UI you can customize the specific mirror or repository from which you’d like to resolve packages in Artifactory for Maven. If you specify the connection, you must also configure the relevant repository integration. 

Git settings for Java - custom Maven package registries for Artifactory

From the Snyk UI you can customize the specific mirror or repository (custom package registries, under specific conditions) from which you’d like to resolve packages in Artifactory for Maven, allowing insight into dependencies that are not hosted in canonical registries.

Note

If you specify the connection, you must also configure the relevant repository integration.

The custom package registry feature currently supports Artifactory with Maven and is available on the Pro and Enterprise plans. Maven analysis can be configured to mirror all requests through a custom package repository, or you can specify additional repositories to use alongside Maven Central.

Custom package registries do not currently work with brokered integrations. If you currently use a brokered integration or need support for other package managers please email contact@snyk.io and we will send you an announcement as soon as support is available.

 
Setup custom package registries

If authentication is required to access your custom registry you will need to first configure the Artifactory package repository integration.

To configure the Artifactory integration go to Integrations > Artifactory and click ‘Connect to Artifactory’ and complete the fields - URL to your Artifactory, username, and password.

Once the integration is set up you can configure Maven settings by navigating to Settings > Languages > Java

You can choose whether to use Artifactory as a mirror or as an additional repository where your artifacts will reside. These settings will be very similar to what you have in ~/.m2/settings.xml.

Mirrors

Choose a value for the type, either ‘direct’ or if using authentication ‘integration’. If using direct you will need to complete the URL, repository name and what it is a mirror of.

The mirror of value can either be a * to mirror everything or you can type in a value for example “central”

image1.png

If using the integration, you will need to choose an integration type and provide the repository name and mirror of details.

image2.png

Repositories

Alternatively, you can configure repositories which will be used as additional locations to check for artifacts.

 
 
 

Additional Snyk support for Java

In addition to the CLI and Snyk UI features, you can also check your Java projects with these plugins: