Best practices for Java and Kotlin
Use this guide to apply Snyk effectively in your technology stack.
Package Registry Integrations (Artifactory/Nexus) - Maven
Artifactory and Nexus Package Registry integrations are available to Snyk Enterprise plan users.
Snyk Open Source uses Artifactory or Nexus to resolve transitive dependencies through private packages.
Snyk can be connected to a publicly available instance using username and password or a private server on your network using the Snyk Broker.
Snyk Open Source provides integrations with Artifactory and Nexus, both as local gatekeepers and interacting with the registry for security testing. See Nexus Repository Manager setup and Artifactory Registry setup
If you are not a Snyk Enterprise user using Artifactory or Nexus, analysis is best performed via CLI, as the build system will retrieve the dependencies and be present locally.
For more information on package registry integrations, including Maven, see the following:
Package registry integrations: Nexus Repository Manager setup and Artifactory Registry setup
Nexus Container Registry: Container security with Nexus integration
Gatekeeper plugins: Artifactory Gatekeeper plugin and Nexus Repository Manager Gatekeeper plugin
Language and package manager considerations
For open source, developers may have decided to use Maven or Gradle, which may impact how you best utilize Snyk to perform the analysis
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.
Maven
Snyk can generate a dependency tree from POM via the Git integration or CLI:
Locally and using CI/CD: Snyk will interact with the package manager to produce a list of dependencies.
Git integration: will approximate the build as if it were built at that time.
Developer dependencies (scope=test) are ignored as they are not pushed to production and are generally considered noise. You can enable them in CLI by adding --dev
Gradle
Snyk will interact with the package manager to produce a list of dependencies.
Typically Gradle will execute code and other actions during the build process that will impact the installed dependencies, so the CLI workflow is recommended if a gradle.lockfile is not present.
The following manifest files are supported:
build.gradle (Groovy DSL) for both SCM and CLI
build.gradle.kts (Kotlin DSL) for CLI only
See the Java and Kotlin page for more details about the supported features.
Other
Sometimes customers develop advanced dependency management strategies and may not necessarily use the standard/well-traveled package managers. For that reason, Snyk has provided test APIs
One-time testing API
Test - will generate a dependency tree. See Test docs.
Snyk Integrations and common usage patterns
Java provides powerful flexibility and configuration options for developers. There can be considerations for testing it, especially with Open Source.
Maven and Gradle Projects using gradle.lockfile
Typically you can instrument testing as part of a build system or adopt a lockfile as part of their process.
It is quite common for large organizations to monitor applications via Git integration, to begin with, daily monitoring, turning on PR checks for only key applications at the start.
As developers become familiar with Snyk capabilities, they widen the scope of applications with PR checks for gating.
Use CI/CD to passively monitor and then turn on gating by using the snyk [product] test and monitor commandsd.
Gradle Projects without a lock file
Use CI/CD to passively monitor and then turn on gating by using the snyk [product] test and monitor commandsd.
Gating and failing the build typically will be turned on one Project to start so that everyone can become familiar with the process and use passive monitoring for the remainder of the portfolio.
Snyk CLI Tips and Tricks
What to test
Use the --help option in the CLI for details of Snyk CLI commands.
🔗 CLI commands and options summary
Testing your own code:
Framework support - see Snyk Code - Supported languages and frameworks.
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.
Open Source libraries
| Maven | Gradle | Unmanaged |
|---|---|---|
|
| Unmanaged Jars - see 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. We recommend you integrate via CLI or Registry earlier in the pipeline and use this as an additional signal/insight into what is in production.
See Snyk CLI for container security for more details.
Infrastructure as code
🔗 Infrastructure as Code security
Fixing vulnerabilities
🔗 Fixing vulnerabilities on Maven projects
Options and plugins
To help generate reports locally or at build time, see snyk-to-html plugin.
See
--jsonand--sarifoptions for generating output that can be programmatically accessed.For advanced filtering options, see snyk-filter.
Additionally, the Snyk team has built plugins to make it easy to integrate Snyk into your workflows:
Gradle Plugin (Community project)
Additional security topics for Java developers
The following is a collection of articles from the Snyk Security team and Developer Relations that impact this ecosystem. For more industry, security, and technology-related articles
Last updated