The snyk test CLI command scans a project's dependencies against Snyk's vulnerability database and reports known issues directly in your terminal. It is the fastest way to check a codebase before you commit, and with a couple of flags it becomes a reliable CI gate. This guide covers the flags that actually matter and the mistakes that make teams disable the scan in frustration.
Installing and authenticating
The CLI ships as an npm package, a standalone binary, or a Homebrew formula. The npm route is the most common:
npm install -g snyk
snyk auth
snyk auth opens a browser to link the CLI to your Snyk account. In CI, skip the interactive flow and export a token instead:
export SNYK_TOKEN=your-service-account-token
Use a dedicated service-account token in pipelines rather than a personal one, so a departing employee does not silently break your builds.
The basic scan
Run snyk test from a directory that contains a supported manifest, package.json, pom.xml, requirements.txt, go.mod, and many others, and it resolves the dependency tree and reports vulnerabilities:
cd my-project
snyk test
The output lists each vulnerability with its severity, the vulnerable path through your dependency graph, and, where one exists, the upgrade or patch that fixes it. The exit code is the important part for automation: snyk test exits non-zero when it finds issues at or above your threshold, which is what lets it fail a build.
One point that trips people up: snyk test is a point-in-time check against your local files. To keep monitoring a project after the scan and get alerted when new vulnerabilities are disclosed against dependencies you already shipped, use snyk monitor, which uploads a snapshot to the Snyk platform.
Gating on severity
By default the scan reports everything, including low-severity findings that will bury the signal you care about. The --severity-threshold flag limits both the report and the failing exit code to a chosen floor:
# Only fail on high and critical
snyk test --severity-threshold=high
The accepted levels are low, medium, high, and critical, and the flag reports the specified level and above. Start strict, fail on critical only, then tighten to high once the backlog is under control. A gate that fails on every low-severity finding on day one just teaches developers to add || true and move on.
Scanning monorepos with --all-projects
A single snyk test scans one manifest in the current directory. Real repositories often have many. The --all-projects flag auto-detects every supported project in the working directory and its subfolders, including Yarn workspaces:
snyk test --all-projects
Combine it with --fail-fast so the scan stops and reports as soon as a project errors out, rather than grinding through the whole tree first:
snyk test --all-projects --fail-fast
If detection is picking up test fixtures or vendored directories you do not care about, --exclude prunes them, and --detection-depth limits how far down the tree Snyk looks. Tuning these two turns a slow, noisy monorepo scan into a targeted one.
Machine-readable output
For dashboards, pull requests, or your own tooling, emit JSON and parse it downstream:
snyk test --all-projects --json > snyk-results.json
For a SARIF report that GitHub code scanning ingests natively:
snyk test --sarif-file-output=snyk.sarif
Writing to a file with the *-file-output flags is safer than piping stdout, because Snyk also prints human-readable status text that will corrupt a naive > file.json redirect on some versions.
Wiring it into CI
A minimal GitHub Actions step looks like this:
- name: Snyk dependency scan
run: |
npm install -g snyk
snyk test --all-projects --severity-threshold=high
env:
SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
Two practical habits keep this from becoming a source of flaky-build complaints. First, cache the CLI install so you are not reinstalling on every run. Second, decide deliberately whether a scan failure blocks the merge or just annotates the PR; blocking is stronger, but only introduce it after the existing backlog is triaged, or you will block every PR on pre-existing debt.
Where the CLI fits, and its limits
snyk test is a strong open-source-friendly entry point, and the CLI itself is free to use with a Snyk account, though scan volumes and some features depend on your plan, so verify the current limits in your account rather than trusting a number in a blog post. Pricing and packaging in this space change often.
It also scans dependencies, not your own code by default; snyk code test is the separate SAST command. And like every command-line dependency scanner, it reflects the state of your lockfile at scan time, so it only helps if it runs consistently. If you are comparing CLI-driven scanning options, our feature-by-feature look covers the tradeoffs, and Safeguard offers a comparable software composition analysis flow if you want to evaluate alternatives side by side.
FAQ
What is the difference between snyk test and snyk monitor?
snyk test is a one-time scan that reports current vulnerabilities and returns a pass/fail exit code, ideal for CI gates. snyk monitor uploads a project snapshot to the Snyk platform so you get ongoing alerts when new vulnerabilities are disclosed later.
How do I make snyk test fail a build only on serious issues?
Use --severity-threshold=high (or critical). The command then reports and exits non-zero only for findings at that level or above, leaving lower-severity noise out of your build gate.
Does snyk test scan my source code?
No. snyk test scans open-source dependencies for known vulnerabilities. To scan your own code with SAST, use the separate snyk code test command.
How do I scan a monorepo with multiple manifests?
Run snyk test --all-projects to auto-detect every supported project, including Yarn workspaces. Add --fail-fast to stop on the first error and --exclude to skip directories you do not want scanned.