Snyk Node.js Scanning: npm and Yarn Dependencies (2026)

Snyk’s Node.js scanner can tell you about vulnerabilities in your npm and Yarn dependencies, but it’s not magic.

Let’s see it in action. Imagine you have a simple package.json:

{
  "name": "vulnerable-app",
  "version": "1.0.0",
  "dependencies": {
    "lodash": "^4.17.10"
  }
}

And you run snyk test:

$ snyk test

Testing /path/to/vulnerable-app...

✗ High severity vulnerability found in lodash
  Description: Regular Expression Denial of Service (ReDoS)
  Info: https://snyk.io/vuln/npm:lodash:20190404
  Introduced through: lodash@4.17.10
  From: lodash@4.17.10
  Remediation:
  | Package | Vulnerable Version | Patched Version |  Reason |
  |---|---|---|---|
  | lodash | <4.17.11 | 4.17.11 |  |

Snyk found a known vulnerability in lodash that was introduced by version 4.17.10. It even tells you the exact version to upgrade to (4.17.11) to fix it.

How Snyk Finds Vulnerabilities

Snyk’s Node.js scanner works by analyzing your project’s dependency tree. When you run snyk test or snyk monitor, Snyk:

1. Reads your manifest file: It looks at package.json (for npm) or package.json and yarn.lock (for Yarn).
2. Builds the dependency tree: It reconstructs the exact, flattened, and resolved dependency tree of your project. This is crucial because vulnerabilities can be nested deep within your dependencies. For example, your-app might depend on library-A, which depends on library-B, and library-B has the vulnerability. Snyk needs to trace this chain.
3. Compares against its database: Snyk maintains a continuously updated vulnerability database. It compares the versions of every package in your resolved dependency tree against this database.
4. Reports findings: If a match is found, Snyk reports the vulnerability, its severity, the affected package and version, and provides remediation advice (usually an upgrade path).

The core of Snyk’s power is its ability to accurately represent your actual installed dependencies, not just what’s declared in package.json. This is why it needs yarn.lock for Yarn projects – it captures the exact versions that were installed, preventing discrepancies that could hide vulnerabilities.

Controlling the Scan

You can influence how Snyk scans your Node.js projects:

• --file=<path/to/package.json>: If your package.json isn’t in the current directory, point Snyk to it.

  snyk test --file=./backend/package.json
  

• --yarn-only / --npm-only: Force Snyk to use only one of the package managers, even if both lock files are present.

  snyk test --yarn-only
  

• --ignore-unmanaged: If you have dependencies installed via methods other than npm/Yarn (e.g., directly copied files), Snyk might warn you. This flag suppresses those warnings.
• --package-manager=<npm|yarn>: Explicitly set the package manager. This is useful if your project has mixed package-lock.json and yarn.lock and you want to prioritize one.

  snyk test --package-manager=yarn
  

• --prune-repeated-dependencies: By default, Snyk will report vulnerabilities for each instance of a vulnerable dependency in the tree. Enabling this flag reports it only once, for the top-level occurrence.

  snyk test --prune-repeated-dependencies
  

The Nuance of Lock Files

The most critical piece of information Snyk uses for Node.js projects is the lock file (package-lock.json or yarn.lock). While package.json declares what dependencies you want, the lock file records exactly which versions were installed and their transitive dependencies. This ensures reproducibility and, more importantly for Snyk, a precise snapshot of your installed packages. Without an accurate lock file, Snyk might be scanning outdated or different versions of dependencies than what’s actually running in your environment, potentially missing vulnerabilities or reporting false positives. When Snyk analyzes a project with both package-lock.json and yarn.lock, it prioritizes yarn.lock if present, as Yarn’s resolution algorithm can sometimes produce a more deterministic tree.

If you ever see Snyk reporting vulnerabilities that you’re sure aren’t present in your actual deployed code, the first thing to check is the integrity and presence of your lock file. A corrupted or missing lock file is a common culprit.

The next step after identifying vulnerabilities is often to understand how to integrate these checks into your CI/CD pipeline automatically.