Snyk for Java developers
Use this guide to understand the best way to apply Snyk in your workflow, and to be aware of key considerations for your chosen technology stack.
Snyk takes a developer-first approach to securing your application. This approach focuses less on overhead-heavy work (such as putting in hard QA gates), and more on building a secure application, providing visibility in a developer’s workflow, and providing actionable insights. The benefits of this approach are to engage developers in security practices as part of their development, without seeing security as a costly overhead.
So we recommend you use Snyk to focus on earlier enablement, not later enforcement. Do not wait until you commit the code to find an issue requiring changes. Snyk provides tools that allow you to test while working on a project to minimize rework. Add a package: test it before writing the code that interfaces with it. Similarly after writing major sections of code, test it before moving on.
This guide focuses on scanning your application code, which are package manager and language specific. Snyk Container and Snyk Infrastructure as Code (IaC) also support your container and infrastructure as code needs.
Before we get started, let's introduce Snyk, as some features mentioned in this document may not be available depending on your Snyk plan or product. Each Snyk product provides key capabilities for the ecosystems you are working in. Snyk Pricing plans determine what features are available.
Snyk has many integrations, designed to satisfy key workflow needs and provide visibility at various stages of development. Additionally each Snyk product provides key capabilities for the ecosystems you are working in.
The following product list indicates what each Snyk product can review with respect to what you are creating, and the plan (Free, Team, legacy Business, and Enterprise) determines what features are available.
Note that there is a monthly limit to the number of tests performed if a particular product is not purchased. You can find the limits outlined here in the first square.
- Snyk Code - scan your own code for security vulnerabilities using source code analysis.
- Snyk Open Source*
- Open Source vulnerability testing and monitoring (All plans)
- Open Source dependency upgrade version bumping (All plans)(Maven)
- License Compliance (Snyk Team, Legacy Business and Enterprise plans)
- Snyk Infrastructure as Code
- If you deploy your applications using Kubernetes deployment files, Terraform, or AWS Cloudformation templates, Snyk can scan for configuration issues that may lead to security vulnerabilities. Supported Environments.
- Snyk Container
- Analyze your container image to make suggestions on utilizing better base images, and identifying known vulnerabilities against container or open source packages in the layers you are creating
- Snyk Cloud: Security from code to cloud and back
- Scan for runtime misconfiguration issues in your cloud and containers, detect infrastructure drift, and fix issues at their source
*Some capabilities may be limited for some languages and package managers
Analyzing your Java source code with Snyk Code is an easy capability to implement, requiring little configuration. So you can use standard Snyk IDE functions, standard Snyk CLI (testing and monitoring) commands, and you can scan repositories using standard Snyk Git repository integration.
Kotlin is currently in beta support for Snyk Code. Contact Snyk for more information.
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.
As you start planning and your code progresses through the pipeline, Snyk can provide different capabilities at each stage, to help you find and fix security issues.
The following public resources are available for all users:
These capabilities focus on enablement, not enforcement. Use Snyk tools to test while working on a project, rather than testing after you commit the code and then discovering issues requiring code rework. Add a package and test it, before writing the code that interfaces with it. Similarly, after writing major sections of code, test the change before you continue.
The following capabilities are available for all Snyk users.
- ​Snyk CLI: A powerful terminal program that allows you to test locally on your machine. Very useful in testing containers and more complex IaC files that are templated with variables (such as Terraform plan files), as well as scanning open source and your own code.
- ​IDE Plugins: for IntelliJ, Eclipse, VS Code, and others: Test your open source packages and first party code as you develop. Additionally test infrastructure as code (IaC) Kubernetes deployment files you create.
- Additionally the Snyk team has built plugins to make it easy to integrate Snyk into your workflows:
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
- Check for known vulnerabilities (Snyk Open Source)
- Create Fix Pull Requests to fix known vulnerabilities (Maven)
- License compliance checks (Snyk Open Source)(Maven)
- Dependency upgrade - positioning updates to address technical debt (Snyk Open Source) (Maven)
Additionally with the Git Integration, you can also monitor the following on a daily basis:
- Infrastructure as code (IaC) with Snyk Infrastructure as Code
With CI/CD integrations
Snyk can passively monitor, and/or provide a QA gate by failing build checks during testing for policy violations.
Snyk provides flexible capabilities, including:
- Dedicated plugins for Jenkins, Circle CI, and others (see relevant marketplaces)
- With Partner Platforms: Azure, Bitbucket, and AWS have built-in pipes/components for use with Snyk.
- Note for Java: using the Git integration with Bitbucket Cloud or using the CLI instead of the prepackaged Bitbucket Pipe is suggested
- (Snyk Enterprise plan only) Snyk can monitor container images and their open source/Linux based packages being used in production via Kubernetes integration, to notify customers of known vulnerabilities for applications in production.
- (All plans) Where a production integration does not exist, use the snyk monitor CLI command to take a snapshot and monitor what is being pushed to production.
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 gatekeeper, 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 and you use Artifactory or Nexus, analysis is best performed via CLI as the build system will retrieve the dependencies and be present locally.
You can place Snyk on your public repositories and have a badge available indicating the security status of your package. See Instant security information with the Snyk security badge.
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 (that is, 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.
​Kotlin​
The following manifest files are supported:
- build.gradle (Groovy DSL)
- build.gradle.kts (Kotlin DSL)
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
Java provides powerful flexibility and configuration options for developers. There can be considerations on how you test it, especially with Open Source.
The following provides some guidance on general rollout recommendations, in addition to commands that are relevant for the Maven/Gradle ecosystems.
- Use the snyk code test command from the root of the project to perform source code analysis.
- Maven
- The snyk test command tests the first manifest it can find, and scans that singular entry point. To scan all manifests:
- 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 args 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.
- As above, --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 Web UI.
- To scan a specific project (for example, myapp), use --sub-project= (that is, snyk test --sub-project=myapp)
- Use --scan-all-unmanaged --all-projects to recursively find all jars under the present working directory.
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 of what is in production.
- See --json and --sarif options for generating output that can be programmatically accessed
For Snyk Open Source, the snyk [product] monitor command is used to push results from the CLI back to Snyk for reporting in the Snyk UI. Don’t forget to use --org= to indicate what Organization to place the monitored results in or retrieve test settings from during the test.
Startups, small teams, individuals, open source maintainers typically onboard their applications via Git getting results in minutes, and starting to address issues almost immediately. Small teams have the benefit of being nimble and determining what works best for their workflow.
With large organizations, and potentially hundreds of applications, a slower approach is recommended to get developer buy-in/adoption and to ensure a positive experience. Passive monitoring would be performed to start, with perhaps one or two key projects having gating enabled early on to familiarize everyone with the process. Gating using PR checks or blocking builds on a wider scope typically starts after the first 30 days.
If you onboard a large number of legacy applications, we suggest you use priority score (typically 700 as a starting place) or criteria such as “known exploit†or “fix availableâ€, to define a starting point to quickly engage developers to start fixing vulnerabilities on key applications.
Typically customers will 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 using the daily monitoring, turning on PR checks for only key applications at the start.
- As developers become familiar with Snyk capabilities, widen the scope of applications with PR checks for gating.
- Some customers use CI/CD to passively monitor and then turn on gating by using the snyk [product] test command.
- Use CI/CD to passively monitor and then turn on gating by using the the snyk [product] test command.
- Gating/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.
This discussion has two sides: what to fix and how to fix it.
Some tools only use the single factor of severity to prioritize issues, but this can still result in thousands of results, with no clear starting point to fix these issues.
Snyk provides more factors to help you prioritize issues, such as having a known exploit, is it fixable, social trending, and others. This can be done both at the project level when looking at a specific project, or Enterprise customers can prioritize across all your projects.
Snyk offers capabilities in this ecosystem to help address issues, both reactively and proactively:
- 1.Being proactive: Use Snyk Advisor for identifying better packages to begin designing. Use the CLI and IDE plugins to test while developing. Add a package, make sure it’s installed and scan for security, before writing your code.
- 2.Remediation advice: Snyk supplies this across integrations on the results screens that calculate the top-level package requiring an update in pom.xml or build.gradle or how to update the line of code to make it secure.
- 3.Automation (Maven):
- You can enable automatic fix pull requests that will be created when new known vulnerabilities are detected and there is a fix available.
- When first importing a project into Snyk it may already have vulnerabilities. Instead of overwhelming you with fixes, Snyk will present the highest priority known vulnerability for you to fix first. Once fixed the next highest priority known vulnerability is presented, in this way you can catch up and fix existing issues. You can speed this process up by fixing all vulnerabilities in a single dependency at a time by enabling the setting Clear backlog faster.
- You can enable dependency upgrade related pull requests, created when new versions of a package are available. This helps with technical debt by providing PR nudges to update dependencies.
We suggest enabling automated PRs on a key project to start before enabling globally, to familiarize development on how to interact with Snyk and security issues.
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