Build an npm Vulnerability Scanner (Free deps.dev)

Article Content

796 npm packages were compromised in the Shai-Hulud attack, affecting over 20 million weekly downloads (Datadog Security Labs, 2025). Traditional npm audit only catches vulnerabilities after they are reported to npm's database. It misses newly published malicious packages, recently compromised legitimate packages, and abandoned dependencies with unpatched CVEs.

If you are relying solely on npm audit to secure your JavaScript projects, you are blind to the threats that matter most.

I built a custom npm vulnerability scanner using the deps.dev API that goes beyond what npm's built-in tools can detect. Here is how to set it up in under 2 minutes.

Get supply chain security updates delivered to your inbox. Subscribe to CyberDesserts for practical security content, no fluff.

Why npm audit Is Not Enough

The npm ecosystem contains over 2 million packages. It is powerful, but it is also a prime target for supply chain attacks. Incidents like Shai-Hulud 2.0, malicious typosquatting packages, and prototype pollution vulnerabilities have made one thing clear: trusting npm packages blindly is dangerous.

For the full threat landscape, see our guide to auditing the npm supply chain.

Traditional tools only scratch the surface. Here is what npm audit checks versus what the deps.dev scanner covers:

The problems compound quickly. Supply chain attacks are increasing, with attackers compromising maintainer accounts. Transitive dependencies create blind spots where one package pulls in dozens of others. Abandoned packages may never receive security updates. And zero-day vulnerabilities in popular packages can affect thousands of projects instantly.

For a deeper look at why npm audit sometimes fails to resolve issues, see npm audit fix not working.

Why deps.dev Works Better

The deps.dev API aggregates data from multiple sources including npm, GitHub, and various security databases. Unlike npm's built-in tools, it provides:

• Comprehensive vulnerability data from multiple security databases
• Release date information for tracking dependency freshness
• Version history and metadata for understanding maintenance patterns
• No authentication required and completely free to use

This approach aligns with continuous security validation rather than point-in-time checks.

Building the Scanner

I created a dependency scanner as an npm script. Here is how to implement it in your projects.

Step 1: Get the Scanner

Clone the complete project with test setup:

git clone https://github.com/cyberdesserts/npm-scanner.git
cd npm-scanner/weather-cli-test
npm install

Or download just the scanner file to your existing project:

curl -o dependency-scanner.js https://raw.githubusercontent.com/cyberdesserts/npm-scanner/main/weather-cli-test/dependency-scanner.js

Step 2: How It Works

The scanner parses package.json to extract dependencies, queries the deps.dev API for each package, collects vulnerability and release date information, and generates a comprehensive report.

The core functionality uses three API endpoints:

// Get version information and release dates
GET /v3/systems/npm/packages/{package}/versions/{version}

// Get vulnerability advisories
GET /v3/systems/npm/packages/{package}/versions/{version}/advisories

// Get all available versions
GET /v3/systems/npm/packages/{package}/versions

Step 3: Running the Scanner

Add this to your package.json:

{
  "scripts": {
    "scan-deps": "node scripts/dependency-scanner.js"
  }
}

Then run:

npm run scan-deps

Reading the Scan Report

Here is what a typical scan report looks like:

Scanning 8 dependencies...

=== DEPENDENCY SCAN REPORT ===

Total packages scanned: 8
Packages with vulnerabilities: 2

⚠️ VULNERABLE PACKAGES:

📦 [email protected]
   Published: 2020-02-20
   Vulnerabilities: 2
   - Prototype Pollution (High severity)
   - Command Injection (Moderate severity)

📦 [email protected]
   Published: 2019-04-16
   Vulnerabilities: 1
   - Timing Attack (Low severity)

📅 OLDEST DEPENDENCIES:
   [email protected] - 1,614 days old
   [email protected] - 1,337 days old

✅ SECURE PACKAGES:
   [email protected] - No vulnerabilities found
   [email protected] - No vulnerabilities found

Results saved to dependency-scan.json

From this example, you can identify several concerns immediately. The high severity prototype pollution in lodash needs immediate attention. Dependencies over 1,000 days old may be abandoned. And 2 out of 8 packages having vulnerabilities shows how quickly risk accumulates.

Fixing What You Find

Once you have identified vulnerabilities, here is how to address them.

Combine with npm audit

Use both tools together for broader coverage:

{
  "scripts": {
    "scan-deps": "node scripts/dependency-scanner.js",
    "security-check": "npm audit && npm run scan-deps",
    "fix-and-scan": "npm audit fix && npm run scan-deps"
  }
}

Use npm audit fix --force cautiously. It may introduce breaking changes, but sometimes security trumps compatibility.

Pin Your Versions

Control when updates happen by using exact versions:

{
  "dependencies": {
    "express": "4.18.0",
    "lodash": "4.17.21"
  }
}

Always commit package-lock.json. Use npm ci in production, never npm install. Make package updates separate PRs for proper scrutiny.

Automate the Scanning

Run the scanner on a schedule with GitHub Actions:

name: NPM Vulnerability Scan
on:
  schedule:
    - cron: '0 9 * * *'
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
      - run: npm run scan-deps

Beyond Basic Scanning

No single tool solves npm security completely. A layered approach works best.

The recent Shai-Hulud attack demonstrated why time-based safety measures matter. Several organisations now implement cooldown periods before adopting new packages. JFrog Curation policies can require packages to be published for a minimum number of days before allowing installation.

For enterprise environments, consider private registry solutions like Artifactory or Nexus with package approval workflows. Never run npm install in production pipelines. Use npm ci only.

Assessing your broader security posture? Take the AI Security Maturity Assessment to identify gaps beyond just npm vulnerabilities.

Key Takeaways

• Accept the reactive reality. Perfect prevention is not possible, so focus on rapid detection and response.
• Layer your defences. Combine scanning, private registries, time delays, and process controls.
• Automate what you can. Manual reviews do not scale. Automated scanning and alerting do.
• Measure continuously. Make vulnerability checking part of your daily workflow.

Next Steps

The npm supply chain security challenge requires technology, process, and culture working together. The deps.dev scanner gives you a foundation to build on.

What you can do today:

• Install and test the scanner using the GitHub repo
• Add Slack or email notifications for critical vulnerabilities
• Integrate into CI/CD to fail builds on high-risk dependencies
• Build custom scoring based on your organisation's risk tolerance

How effective is your current approach to npm vulnerabilities? I would welcome feedback on this implementation. Feel free to reach out, contribute improvements, or fork the project for your specific needs.

Get started with the npm Vulnerability Scanner →

The npm threat landscape evolves weekly. Subscribers get notified when new attacks emerge and when this scanner is updated. No sales pitches, no fluff.

Last updated: December 2025

This article is part of our npm security series. See also: Auditing the npm Supply Chain and Shai-Hulud npm Attack.

References and Sources

1. Datadog Security Labs. (2025). Shai-Hulud npm Supply Chain Attack Analysis. 796 packages compromised affecting 20M+ weekly downloads.
2. deps.dev. (2025). Open Source Insights API Documentation. Google.
3. CISA. (2025). Alert: Widespread Supply Chain Compromise Impacting npm Ecosystem.
4. Unit 42. (2025). Self-Replicating Worm Analysis. Palo Alto Networks.