Snyk Documentation

CLI - Test

Test a local project

To only test your project for known vulnerabilities, browse to your project’s folder and run snyk test:

cd ~/projects/myproj/

snyk test takes stock of all the local dependencies and queries the snyk service for related known vulnerabilities. It displays the found issues along with additional information. For Node.js, Ruby, Java projects, it also suggests remediation steps.

When snyk test runs, it tries to autodetect your project type by looking for the following files, in this order:

  1. yarn.lock
  2. package-lock.json
  3. package.json
  4. Gemfile.lock
  5. pom.xml
  6. build.gradle
  7. build.sbt
  8. Pipfile
  9. requirements.txt
  10. Gopkg.lock
  11. vendor/vendor.json
  12. obj/project.assets.json
  13. packages.config
  14. composer.lock

Monorepos and projects with multiple manifest files

For projects that have multiple manifest files, you can specify the file that Snyk should inspect for package information using the file flag:

$ snyk test --file=package.json

Manifest files with custom names

If your manifest files are from a supported language but have a custom name you can let Snyk know about it by using a combination of the file flag and the package-manager flag:

$ snyk test --file=req.txt --package-manager=pip

Testing dev dependencies

Many package managers allow calling out separately dependencies which are to be used only in a development/test context (i.e don't get eventually shipped to production). By default Snyk does not scan these dependencies. If you want your dev dependencies to be included in the scan use the dev flag:

$ snyk test --dev

Setting severity threshold

To have a better control over your tests, you can pass the severity-threshold flag to the snyk test command with one of the supported options (low|medium|high). With this flag, only vulnerabilities of provided level or higher will be reported.

$ snyk test --severity-threshold=medium

Note: low option currently has the same effect as running without specifying the threshold, i.e. all vulnerabilities will be reported.

Note for Node.js:

Since snyk test looks at the locally installed modules, it needs to be run after npm install or yarn install, and will seamlessly work with shrinkwrap, npm enterprise or any other custom installation logic you have.

Note for Java:

Since snyk test looks at the locally installed modules, it needs to run after mvn install.

Note for Scala:

In order to use the CLI to test against your build.sbt manifest file, you’ll need to first install the sbt-dependency-graph plugin.
Running snyk test on your Scala projects without this plugin will throw the following error:

Error: Missing plugin sbt-dependency-graph (
Please install it globally or on the current project and try again.

Note for Golang:

Since snyk test inspects the locally installed modules, it needs to run after the  vendor/ folder has been populated via dep ensure or govendor sync. In addition, the GOPATH environment variable must be set correctly.

Note for .NET:

Since snyk test inspects the locally installed modules, it needs to run after the packages/(.NET) or obj/(.NET Core) folder has been populated via Visual Studio or dotnet restore.

The CLI does not currently auto-detect .sln files, so for .NET and .NET Core projects you can specify in the <code">--file parameter the location of the solution file and the CLI will run on all the projects it finds inside.

$ snyk test--file=myApp.sln


Note for PHP:

Since snyk test inspects the locally installed modules, it needs to run after the  composer.lock file has been created by composer install.

Test a public GitHub repository

To test a public Github repository, run snyk test and include the Github URL to the repo.

$ snyk test

The following git URL formats are supported:

  1. git://
  3. user/project#commit-ish

This also works for Bitbucket and GitLab.
You can also test a public npm package or Github project via the Test page on

Test a public npm package

You can also use snyk test to scrutinise a public package before installing it, to see if it has known vulnerabilities or not. Using the package name will test the latest version of that package, and you can also provide a specific version or range using snyk test module[@semver-range].

snyk test lodash snyk test ionic@1.6.5


Test a Maven or Gradle project with variables

You can pass variables to snyk test running on Maven or Gradle projects. This is useful when you want to test a specific profile (in Maven) or configuration (in Gradle), or pass system properties. This is done by sending flags after a double-dash option when running snyk test. Note that all flags after the double-dash option will be used as Maven or Gradle flags.

For example, suppose you want to test a specific Maven profile: prod. Running the following will test this profile:

snyk test -- -Pprod

In another example, if you use a system property in your pom.xml file, e.g:  <version>${pkg_version}</version>, you can define the system property in snyk test as follows:

snyk test -- -Dpkg_version=1.4

For testing a Gradle project with test dependencies, you would be able to pass the appropriate configuration to snyk test:

snyk test -- --configuration testCompile


Test Results

After running snyk test you will presented with a list of vulnerabilities, including the severity, a description of the issue and a link where you can learn more about the specific vulnerability issue.  Depending on the language of the project you have tested you may also see remediation advice providing details on how you can manually fix the vulnerability.

If you are testing a node.js or yarn project you can also use snyk wizard to fix your project.



Open source projects

Tests against open source projects are free and don't count towards your test usage. If your source code is available publicly on the internet, you can mark your project as open source by following these steps.

  1. If you haven’t done so already, run snyk monitor in your terminal to create a project on Snyk
  2. On the Snyk website, view your projects and select the CLI project you just created
  3. Click on “settings” from the right hand side of this page to change the project settings
  4. Enter a git URI to the source code for your project where it says “Git remote URI”. If your code is hosted on GitHub, you can find this by clicking the “Clone or download” button and copying the URI.
  5. If we are able to verify that the URI points to a git repository then your project will be marked as open source and will no longer be tracked against your private project test usage.