Scanning npm and pip Dependencies for Vulnerabilities Inside Claude Code

May 2026 · Novadyne

Every npm install or pip install pulls in dozens of transitive dependencies. Each one is a potential attack surface. Most teams know this, but checking for vulnerabilities usually means switching to a separate dashboard, running a CI pipeline, or pasting package names into a web form.

VulnFeed is an MCP server that brings vulnerability scanning directly into your AI coding assistant. If you use Claude Code, you can scan your project's dependency lockfiles and get prioritized CVE reports without ever leaving the terminal.

This tutorial walks through setup, scanning, and interpreting results.

Install VulnFeed MCP

VulnFeed ships as a Python package. Install it with pip or run it directly with uvx:

# Option A: install globally
pip install vulnfeed-mcp

# Option B: run without installing (recommended)
uvx vulnfeed-mcp

Then add it to your Claude Code MCP configuration. In your project's .mcp.json:

{
  "mcpServers": {
    "vulnfeed": {
      "command": "uvx",
      "args": ["vulnfeed-mcp"]
    }
  }
}

Restart Claude Code. You should see VulnFeed's tools listed when you run /mcp.

Scan a project

The simplest way: just ask Claude to scan your project for vulnerabilities. Claude will call the right VulnFeed tool automatically.

"Scan this project for dependency vulnerabilities"

VulnFeed detects your lockfile format (package-lock.json, yarn.lock, Pipfile.lock, requirements.txt) and sends the dependency list to be checked against the National Vulnerability Database (NVD) and GitHub Security Advisories.

For more targeted scans, you can ask Claude to use specific tools:

• scan_lockfile — scan a specific lockfile path
• scan_project — auto-detect and scan all lockfiles in a directory
• check_package — check a single package and version
• lookup_cve — get full details on a specific CVE

Understanding the results

VulnFeed doesn't just list CVEs. It ranks them by EPSS score — the Exploit Prediction Scoring System, which estimates the probability that a vulnerability will be exploited in the wild within the next 30 days.

This matters because not all CVEs are equal. A project with 40 known vulnerabilities might have 38 that are theoretical and 2 that are actively exploited. EPSS tells you which two to fix first.

Results include:

• CVE ID and description
• CVSS score (severity rating, 0–10)
• EPSS score (exploitation probability, 0–1)
• EPSS percentile (how this vuln compares to all known vulns)
• Affected versions and fix versions (when available)
• Source (NVD, GitHub Advisory, or both)

Vulnerabilities are sorted by EPSS score descending, so the most likely-to-be-exploited issues appear first.

Example: scanning an Express.js project

Here's what a typical scan looks like for a Node.js project:

You: "Scan this project for dependency vulnerabilities"

Claude: I'll scan your package-lock.json using VulnFeed.

Found 4 vulnerabilities in 847 packages:

1. CVE-2024-21538 (cross-spawn) — CVSS 7.5, EPSS 0.87
   Affected: <7.0.5 | Fix: 7.0.5
   Command injection via args on Windows

2. CVE-2024-47764 (cookie) — CVSS 5.3, EPSS 0.42
   Affected: <0.7.0 | Fix: 0.7.0
   Cookie header parsing allows prototype pollution

3. CVE-2024-37890 (ws) — CVSS 7.5, EPSS 0.03
   Affected: <8.17.1 | Fix: 8.17.1
   Denial of service via large WebSocket frame

4. CVE-2024-43788 (webpack) — CVSS 6.1, EPSS 0.01
   Affected: 5.0.0–5.94.0 | Fix: 5.94.0
   XSS in development server error overlay

The EPSS scores immediately tell you: cross-spawn is the urgent one (87% exploitation probability), cookie is worth fixing soon, and ws and webpack are lower risk. Without EPSS, you'd just see four CVEs with similar CVSS scores and no clear priority.

Monitoring for new vulnerabilities

VulnFeed also supports ongoing monitoring. Register a project and check for new alerts periodically:

• monitor_project — register a project's dependencies for monitoring
• check_alerts — check for new CVEs against monitored projects
• list_monitored — see all monitored projects
• unmonitor_project — remove a project from monitoring

This is useful for long-running projects where you want to catch new disclosures without re-scanning manually.

Supported lockfile formats

• package-lock.json (npm)
• yarn.lock (Yarn)
• Pipfile.lock (Pipenv)
• requirements.txt (pip)

The scanner parses the lockfile locally and sends only package names and versions to the vulnerability database. No source code leaves your machine.

Free tier and pricing

VulnFeed has a free tier: 10 scans per day, 1 monitored project. No signup required.

For heavier usage, there's a $14/month subscription for unlimited scans, or x402 micropayments at $0.01 per scan for pay-as-you-go (requires a USDC wallet on Base).

When to scan

Good checkpoints for dependency scanning:

• Before shipping: "Scan for vulnerabilities before I push this release"
• After adding dependencies: "I just added three new packages, check them for known CVEs"
• During code review: "Are any of the dependencies in this PR's lockfile changes vulnerable?"
• Periodic audits: Set up monitoring and check alerts weekly

Because VulnFeed runs inside your coding agent, there's no context switch. The scan results are right there in the conversation, and Claude can immediately suggest fixes based on the fix versions reported.