Dependency Scanning: How to Keep Your npm Packages Secure in 2026

Dependency scanning is not optional anymore. It is a baseline hygiene practice in the same category as having tests and a linter.

How CVEs Get Into Your Dependencies

Understanding the entry points helps you build effective defenses.

Direct dependency vulnerabilities

A package you directly npm installed has a vulnerability disclosed. Example: your application uses lodash@4.17.4, and CVE-2021-23337 is disclosed — a prototype pollution vulnerability in lodash.set. You are directly affected.

This is the easiest case. Your package.json references lodash directly. The fix is npm install lodash@latest.

Transitive dependency vulnerabilities

A package you depend on has a dependency with a vulnerability. Your package.json does not mention this package at all — it is three levels deep in the dependency tree.

You cannot fix this by editing your package.json. You need to either: 1. Update express (hoping the new version depends on a patched qs) 2. Use npm install qs@latest --save-dev to force a specific version (via resolutions field) 3. Add a overrides entry in package.json:

Malicious packages (supply chain attacks)

A package maintainer''s npm account is compromised, and a malicious version is published. Or a package with a name similar to a popular one is published hoping developers mistype it (typosquatting). Or a maintainer deliberately introduces malicious code (event-stream incident).

This class of attack is harder to detect with CVE-based scanning because there is no CVE — it is a new malicious version of a previously clean package, not a vulnerability in existing code.

Defenses: - Pin exact versions in package-lock.json (do not use npm install --no-save) - Use npm ci (not npm install) in CI to enforce the lockfile - Monitor for unexpected new versions of your direct dependencies

Dependency confusion attacks

An attacker publishes a public npm package with the same name as your internal private package. npm install may prefer the public version. This is a particularly dangerous attack against organizations using private registries.

npm audit: Strengths and Limitations

npm audit is built into npm and is the first tool most developers encounter.

Sample output:

What npm audit does well: - Checks your dependency tree against the npm Advisory Database - Available everywhere npm is installed, no additional tools needed - --json output is scriptable - npm audit fix handles straightforward updates automatically

What npm audit misses: - Vulnerabilities not yet in the npm Advisory Database - License compliance issues - Security scoring beyond severity classification - Code pattern analysis (only checks known CVE databases) - Container or OS-level vulnerabilities

In CI, use npm audit as a gate:

Snyk: Deeper Analysis

Snyk maintains its own vulnerability database (larger than npm''s) and provides several advantages over npm audit:

• More vulnerabilities in its database, particularly for less-mainstream packages
• License compliance checking (useful for enterprise legal requirements)
• Actionable remediation advice, including upgrade path details
• Container and IaC scanning in the same tool
• A free tier for open source projects

Snyk in GitHub Actions:

Understanding CVSS Scores

The Common Vulnerability Scoring System (CVSS) is a standardized 0-10 scale for vulnerability severity. Understanding it helps you triage findings intelligently rather than treating every "high" as equally urgent.

The CVSS vector string explains the score:

The key insight: CVSS scores measure the vulnerability''s theoretical maximum severity. Actual risk depends on your specific context:

Always read the vulnerability description, not just the score. A CVSS 9.8 in jest (your test runner) is not a production security issue.

Lockfile Security

The lockfile (package-lock.json or yarn.lock) records the exact version of every package in your dependency tree, including all transitives. Committing the lockfile is a security requirement, not just a convenience.

Lockfile integrity checks:

The npm audit signatures command (npm 7.25+) checks that the cryptographic signatures of your installed packages match the registry signatures. This is a direct defense against supply chain attacks where a published package is tampered with after the signature was created.

Automating Updates with Dependabot and Renovate

Manual dependency updates are unreliable — engineers defer them, forget them, or batch them into quarterly "dependency update sprints" that create large diffs and regression risk.

Automated update PRs (Dependabot or Renovate) create one PR per dependency update, keeping updates small and reviewable.

Dependabot (GitHub native)

Renovate (more configurable)

Renovate''s vulnerabilityAlerts creates PRs for known vulnerabilities immediately, regardless of the regular update schedule. For security updates, you want daily (or immediate) updates — not weekly.

ZeriFlow''s Approach to Dependency Security

ZeriFlow''s Advanced Scan (Pro plan) analyzes your GitHub repository or ZIP upload for security issues including:

• Hardcoded secrets in source files
• Known-vulnerable dependency versions based on package.json and package-lock.json parsing
• Insecure code patterns (SQL injection vectors, prototype pollution, unsafe deserialization)
• Exposed sensitive file patterns

Unlike npm audit, ZeriFlow also scans your deployed application from the outside — checking whether your application reveals version information that would help attackers identify known vulnerabilities:

These headers are security-relevant because they confirm to an attacker that specific known-vulnerable versions are in use. ZeriFlow flags their presence and recommends removing them.

Running ZeriFlow on a deployed URL takes 60 seconds and covers the runtime surface — use it in combination with npm audit and Snyk, which cover the source-level surface.

Triaging False Positives

Not every vulnerability report represents actual risk. A structured triage process prevents both under-reaction (ignoring real issues) and over-reaction (burning engineering time on non-issues).

Document your triage decisions in a vulnerability registry:

Accepted risks should have a review date. Treat an accepted risk that has not been reviewed for 90 days as a new finding.

Conclusion

Dependency scanning is a continuous practice, not a one-time audit. The npm ecosystem releases packages and security advisories every day. Your dependency tree is not static. A clean audit today will have findings next month.

The practical baseline for 2026: 1. Run npm audit in CI and fail builds on high/critical 2. Add Dependabot for automated security update PRs 3. Use npm ci (not npm install) everywhere in CI 4. Run Snyk for deeper analysis and transitive dependency coverage 5. Scan your deployed application with ZeriFlow to catch what source-level tools miss

Run an Advanced Scan on ZeriFlow to check your repository for hardcoded secrets, CVE patterns, and insecure code — Pro plan includes GitHub repo and ZIP upload scanning.