Snyk CLI cheat sheet
November 26, 20200 mins read
Last update: April 2022
Have an older version of the Snyk CLI cheat sheet? Download the latest version below.
The Snyk CLI is an excellent and powerful tool to scan your applications, containers, and infrastructure as code for security vulnerabilities. In this cheat sheet, we will look at the most powerful features our CLI has to offer. You can use the CLI for scanning and monitoring on your local machine, but you can also integrate it into your pipeline. Regardless of how you use it, the Snyk CLI is the go-to tool to test, monitor, and remediate known vulnerabilities in your applications.
We are continually improving our CLI, and it has far more power than we can ever address in a single cheat sheet. For a more detailed overview of our CLI, please look at our Snyk CLI documentation. If you want to know more about what the CLI can do for a specific language or build system, check our language support page:
Java (maven | Gradle)
.Net (Nuget, Paket)
Python (Pip, Poetry)
Golang (dep, govendor)
Let’s start from the beginning. If you haven’t installed the Snyk CLI yet, you should do this first. Currently, you have the option to install the Snyk CLI using either npm, Homebrew, Scoop, or by downloading a specific binary from GitHub.
npm install snyk -g
brew tap snyk/tap && brew install snyk
scoop bucket add snyk https://github.com/snyk/scoop-snyk scoop install snyk
A manual installer is available on Snyk’s GitHub page.
Once you've installed the CLI, you have to authenticate with your Snyk account. There are a few ways to do this.
When you call
snyk auth the browser reroutes to the signup or sign-in page where you can authenticate or signup.
Alternatively, you can run
snyk auth [api-token] providing a Snyk API token argument that you can retrieve from your account page.
The last option, which we specifically recommended for CI testing, is to create an environment variable called
SNYK_TOKEN. All Snyk CLI commands will use this without explicitly running
Pro tip:Make sure you update and reinstall the CLI often. We are fixing and releasing new versions of the CLI very often. You do not want to miss out on new and improved features.
The Snyk CLI takes in a command, followed by several options. Make sure you run the CLI commands within the project folder. Let's look into what each of these commands does.
snyk test command tests a local project for known vulnerabilities. It provides information about those vulnerabilities, their severities, types and descriptions, the number of vulnerable paths, remediation actions, and more. The Snyk CLI auto-detects your manifest files and tests the first it finds. Note that Snyk looks for local dependencies to test for vulnerabilities. As a result, you must run the necessary steps to download your dependency tree before running the
snyk test, such as
npm install, mvn install, dotnet restore, or
Snyk test is also handy within a CI-pipeline. Running a
snyk test when building the binary directly shows whether your project contains vulnerabilities. If you like, you can even break your pipeline and demand a full stop. When you call
snyk test from a script, you just need to check the exit code. If the exit code is 0, everything is fine, and there are no vulnerabilities found. If it is something else, you probably have some work left.
You can test a specific manifest if you have a project that contains multiple. Use the
--file flag to specify the file you want to scan.
$ snyk [cmd] --file=package.json
Similarly, you can specify the package manager using the
--package-manager flag. This is useful in the exceptional case that snyk cant automatically detects the package manager.
$ snyk test --file=req.txt --package-manager=pip
If you want to test all projects in a folder, you can use the
--all-projects flag. It runs an auto-discovery to scan the current directory and test all manifest files found. By default, Snyk scans the current directory and three extra levels deep. To change the depth level, just add the
$ snyk test --all-projects --detection-depth=4
However, Snyk does not by default test your dev dependencies, as many consider this noise compared to production vulnerabilities. If you want Snyk to include your dev dependencies as well, use the
$ snyk test --dev
Another useful flag to use on the test command, as well as on other Snyk commands, is the
--org flag. This associates a test or any Snyk command with a specific organization. Organizations are containers in which you can group projects, and they can have multiple users associated with them. This is particularly useful when working in teams and creating snapshots with a
snyk monitor. If you do not specify an org, your results are associated with your default org.
$ snyk [cmd] --org=<org_id>
If you want to test public repositories from the command line, we've got you covered. You can provide the URL of the public repository directly into the command. It only works on npm repositories if the
package-lock.json is available. Try it out:
$ snyk test https://github.com/snyk/goof
You can also test packages in npm remotely by passing in the package name only, testing the latest release, or fully qualifying the package name and version.
$ snyk test lodash $ snyk test email@example.com
After running a snyk test on a project, the output is served to you in three sections.
Issues to fix by upgrading:By updating the library as suggested, you will remove one or more vulnerabilities found in your project.
Patchable issue:There is no update available that fixes the problem. However, Snyk created a patch to fix the vulnerability.
Issues with no direct upgrade or patch:There is no update available for the dependency you imported. A vulnerability might actually be in one of the transitive dependencies. If there is already a newer version of the transitive dependency that fixed the vulnerability, we show you that as well. In some ecosystems, you can manually replace transitive dependencies, so this is valuable information.
For every vulnerability that the CLI displays in either of the three sections, you can see a description, the severity, and a link where you can learn more about the specific vulnerability issue.
If you prefer the CLI output in the JSON format, we have a flag for that,
--json. You can use the JSON output to format the results however you like.
$ snyk test --json
Saving your scan output in a JSON file is even more straightforward. With the
--json-file-output flag, you can directly save the result to the filename you desire for later inspection. In the meantime, you will get the readable output, as shown earlier in your console. This is a perfect solution for CI-pipelines when, for instance, you want to display the results for a specific build in a dashboard. Just try:
$ snyk test --json-file-output=vuln.json
Also, note we have a Snyk JSON to HTML mapper that can format your results into a nice HTML-based report you can show to your manager.
You can control the CLI output by severity with the
--severity-threshold flag. If you are not interested in the medium or low severe vulnerabilities, you can leave them out of the equation by doing the following:
$ snyk [cmd] --severity-threshold=high
snyk monitor command takes a snapshot of your project and uploads the results to the Snyk website. Although
snyk monitor uses
snyk test under the hood, it is important to know that it is not a replacement—Snyk monitor takes a snapshot and monitors that snapshot over time. When any new vulnerabilities or new remediation paths that your project benefits from are found, it will be sent to you as an alert via your chosen communication channel.
In a CI environment, you typically run a
snyk test first to see if there are vulnerabilities at this moment. If there are any, you could break your build, depending on the use case. When you continue,
snyk monitor is typically used to create a snapshot for that version, so it is monitored over time. A great time to do this is right before going to production. When you are comfortable with a certain level of vulnerabilities, the
snyk monitor will help you not digress over time.
It's important when running
snyk monitor that you specify enough information to ensure your snapshot ends up in the expected location. If you are a member of many organizations, then be sure to specify which one to send your snapshot to via the
--org flag. If you have similar project names, you can override the default name Snyk gives your snapshots by entering your desired name using the
$ snyk monitor --file=package.json --project-name=myapp --org=myorg
Suppose your application contains a vulnerability with no remediating patch or update available or a vulnerability that you do not believe to be currently exploitable in your application. In that case, you may want to tell Snyk to ignore the vulnerability for a certain period. To use the ignore command, first run
snyk test and retrieve the vulnerability ID, which you can find in the CLI output. Now you can ignore this vulnerability by using the following command:
$ snyk ignore --id=npm:tough-cookie:20160722 --expiry=2019-04-30 --reason='Not currently exploitable'
--reason flags are optional. By default, the security vulnerability is ignored for 30 days.
Note: the snyk ignore command will create a
.snyk file holding the information about the security issue you are ignoring.
Snyk Container is the CLI capability to scan container images like Docker images. Previously this was available using the
--docker flag in the CLI.
Similar to scanning and monitoring your application, you can scan your Docker images using Snyk.
When downloading images for Docker Hub, you can scan and monitor that image like this:
$ snyk container test <image>:<tag> $ snyk container monitor <image>:<tag>
When adding a Dockerfile to either of these commands, Snyk will give you remediation advice on the base image you are using, among other things. If there are different base images available for the image you have built, we can point you to these alternatives.
Snyk Container does not only support Docker containers but also distorless images. These images can be scanned like this:
$ snyk container test gcr.io/distroless/base | head
Also, container archives can be scanned and monitored using Snyk's container capabilities. Scanning works for both Docker container archives and Open Container Initiative (OCI) images.
$ snyk container test docker-archive:container.tar $ snyk container test oci-archive:container.tar
Like scanning your applications, the
--json-file-output flags are available for seamless integration with your own systems.
Snyk Infrastructure as Code (Snyk IaC)
With the Snyk Infrastructure As Code scanning capabilities, we enable developers to find and fix misconfigurations that can lead to security problems. With the
snyk iac command, you can also utilize this functionality in the Snyk CLI on your local machine or in your CI environment. Now, you will get feedback as early as possible in your development cycle. Snyk IaC is available with support for Kubernetes, Helm Charts, and Terraform AWS resources.
If you want to scan a Kubernetes or Terraform file, you can try something like this:
$ snyk iac test /path/to/Kubernetes.yaml $ snyk iac test /path/to/terraform_file.tf
Similar to snyk test the issues found with snyk iac show a description and a severity level. If you need this output in a JSON format to integrate with your system, the
--json and the
--json-file-output flags are also available here:
$ snyk iac test /path/to/Kubernetes.yaml --json
Snyk IaC also lets you detect, track, and alert on infrastructure drift and unmanaged resources:
$ snyk iac describe <OPTIONS>
If you are not sure what command to use or how a specific flag works, you can always use
--help switch or call
$ snyk auth --help $ snyk container --help
If something does not work, you can ask the CLI to output the debug logging with the
-d flag. When talking to our fantastic support team, they will most likely ask you to do this as well:
$ snyk [cmd] -d
Are you running out of tests on an open source project?
Snyk scanning is free and unlimited for open source development. However, we do not always recognize an open source project. If you get prompted in the CLI output that you are running out of tests, you can take the following steps to prove your project is in fact, open source.
Navigate to your application in the browser. (the direct URL is in the CLI output)
Click Settings from the menu
Enter the URL for your open source repository in the Git remote URI field.
Unexpected test results?
For the best result, rebuild your complete project before running any of the CLI commands. If the output of a
snyk test or
snyk monitor is not as expected, please run your build tool to download and install all dependencies.
$ npm install $ mvn install $ dotnet restore $ dep ensure
Removing your API key and configuration
If you have authenticated your CLI using
snyk auth, you can remove your token from the configuration using the following command:
$ snyk config unset api
For more information on other config settings, please call:
$ snyk help config
Check your version
Always use the latest version of our CLI. We release a new version multiple times a week and sometimes even more.
Ensure you (re)install the latest version using your package manager as described in the first section, or look for the latest build on our GitHub repo.
To check your current version, simply run:
$ snyk --version
Check the documentation
Specific projects and ecosystems have specific needs. Please check the CLI documentation and the language support documentation to find help for a more specific use-case.
Automatically find & fix vulns
Snyk provides one-click fix PRs and remediation advice for your code, dependencies, containers, and cloud infrastructure.