The most surprising thing about Snyk is that it doesn’t just find vulnerabilities; it actively helps you prevent them by integrating into your development workflow.

Let’s see Snyk in action. Imagine you’re starting a new Node.js project.

First, you’ll install the Snyk CLI globally:

npm install -g snyk

Next, you need to authenticate Snyk with your account. This links the CLI to your Snyk project and allows it to report findings.

snyk auth

This command opens a browser window. You’ll log in to your Snyk account, and a token will be automatically passed back to your CLI. If you’re doing this in a headless environment, you’d get the token from your Snyk UI and run:

snyk auth <your-token-here>

Now, let’s scan your project. Navigate to your project’s root directory. If it’s a Node.js project, Snyk will automatically detect your package.json.

cd /path/to/your/nodejs/project
snyk test

Snyk will analyze your project’s dependencies. It looks at your package.json and package-lock.json (or yarn.lock) to build an accurate dependency tree. Then, it compares the versions of each direct and transitive dependency against Snyk’s vulnerability database, which is updated multiple times a day.

Here’s what a typical output might look like if Snyk finds issues:

Testing /path/to/your/nodejs/project...

Unsupported package manager: Please use a supported package manager (npm, yarn, pnpm, maven, gradle, pip, poetry, composer, gem, docker, terraform, helm, cloudformation).
Continue? [yes/No]

Ah, a common first hurdle! If you see "Unsupported package manager," it usually means Snyk couldn’t automatically detect how your project is built. For modern Node.js projects using npm or yarn, this is rare. If you’re using a tool like pnpm, you might need to tell Snyk explicitly:

snyk test --package-manager=pnpm

Let’s assume it’s a standard npm project and it does find vulnerabilities. You’ll see something like this:

Testing /path/to/your/nodejs/project...

✗ High severity vulnerability found in lodash
  Description: Regular expression Denial of Service (ReDoS)
  Info: https://snyk.io/vuln/SNYK-JS-LODASH-1018905
  Introduced through: lodash@4.17.15
  From: lodash@4.17.15
  Fix available: upgrade lodash to 4.17.21

  (1 more vulnerability found)

Organization: default
Package manager: npm
Project name: your-project-name
Tested versions: 150
Number of vulnerabilities: 2
  High: 1
  Medium: 1

Run "snyk monitor" to continuously monitor your project for new vulnerabilities.

The output breaks down the vulnerabilities by severity (High, Medium, Low), names the vulnerable package (e.g., lodash), provides a brief description, a link to the Snyk vulnerability database for more details, and crucially, the Introduced through and From fields, which show you how the vulnerable package ended up in your project. The Fix available line is your direct path to remediation.

To fix the lodash vulnerability, you’d upgrade it:

npm update lodash

Or, if you want to be more explicit and ensure you’re getting the exact version recommended by Snyk:

npm install lodash@4.17.21

This works because Snyk’s vulnerability database maps specific package versions to known security flaws. By upgrading to a version that is not listed as vulnerable, you eliminate that specific risk. The npm update command respects your package-lock.json and package.json to find the latest compatible version, while npm install lodash@4.17.21 forces that specific version.

After running npm update or npm install lodash@4.17.21, you’d run snyk test again to confirm the vulnerability is gone.

snyk test

The output should now show zero vulnerabilities, or at least fewer than before.

Testing /path/to/your/nodejs/project...

No vulnerabilities found.

Beyond just testing, snyk monitor is key for ongoing security. It takes a snapshot of your project’s dependencies and continuously monitors them in the background, alerting you via email if new vulnerabilities are discovered in the versions you are currently using.

snyk monitor

This command uploads your project’s dependency manifest and the current versions to Snyk’s cloud. Snyk then periodically re-checks these versions against its database. If a new vulnerability is found that affects your installed version, Snyk will trigger an alert.

One aspect people often overlook is how Snyk handles transitive dependencies. When you npm install express, you’re not just installing express; you’re also installing all the packages express depends on, and all the packages those depend on, and so on. Snyk’s snyk test command builds this entire tree and checks every single node in it for vulnerabilities, not just your top-level dependencies. This is why you might see vulnerabilities in packages you didn’t directly install.

The next step after a successful scan is to integrate Snyk into your CI/CD pipeline to automate these checks on every commit or pull request.

Want structured learning?

Take the full Snyk course →