Claude Code's Security Review Has a Blind Spot — It Doesn't Check Your Dependencies

The Claude Code source leak revealed the exact prompt used for security reviews on pull requests. It’s one of the most thorough AI security review prompts we’ve ever seen: SQL injection, XSS, authentication bypass, deserialization attacks, privilege escalation, cryptographic weaknesses. Over 200 lines of carefully crafted instructions.

But buried in the “Hard Exclusions” section is this line:

9. Vulnerabilities related to outdated third-party libraries. These are managed separately and should not be reported here.

“Managed separately.” By what?

There’s no built-in dependency scanner in Claude Code. No CVE database lookup. No lock file analysis. That single line essentially says: we know this is a problem, but we’re not solving it here.

Why This Matters More Than It Sounds

When you vibe-code a Node.js project, Claude pulls in packages it knows from training data. Training data that’s months old. It doesn’t check whether express@4.17.1 has a path traversal CVE. It doesn’t know whether that jsonwebtoken version has a known bypass. And it has no idea whether any of your transitive dependencies are listed in CISA’s Known Exploited Vulnerabilities catalog.

The security review catches bad code you write. Nobody’s catching bad code in the packages the AI installs for you.

Let that sink in: Claude Code has a sophisticated system to review the code it generates, but no system to verify the safety of the code it imports.

The Numbers

This isn’t theoretical:

• npm supply chain attacks have mass-targeted common typos of popular packages throughout 2024 and 2025
• CISA’s KEV catalog (vulnerabilities actively exploited in the wild) contains over 1,200 entries, many in widely-used libraries
• The average Node.js project has 300 to 900 transitive dependencies, each one a potential attack surface you never reviewed
• Log4Shell (CVE-2021-44228) was a single dependency vulnerability that affected virtually every Java application on the planet

The Three-Layer Problem

Here’s how to think about application security in an AI-assisted development workflow:

Layer 1: Code review    → Claude's security prompt handles this
Layer 2: Known CVEs     → Nobody handles this (the gap)
Layer 3: Supply chain   → Nobody handles this either

Claude’s security prompt is excellent at Layer 1. It catches injection vulnerabilities, auth bypasses, XSS, and deserialization attacks in the code you write. That’s real, valuable work.

But Layer 2 (known vulnerabilities in legitimate packages) and Layer 3 (malicious packages pretending to be legitimate) are completely unaddressed. The prompt doesn’t just miss them — it explicitly excludes them.

How to Fill the Gap

Layer 2: Known CVEs in Dependencies

This is what OtterSight was built for. One command, runs locally, no account needed:

npx @ottersight/cli scan .

It matches your lock files against three vulnerability databases:

• NVD (via Grype) — the US National Vulnerability Database
• CISA KEV — vulnerabilities actively exploited in the wild
• EUVD — the EU Vulnerability Database from ENISA (relevant for CRA and NIS2 compliance)

Output is a severity-sorted table with CVSS scores, EPSS exploitation probability, and KEV flags. No AI interpretation. Just facts from real databases matched against your actual dependencies.

Giving Claude Access to CVE Data

If you want Claude itself to check dependencies during development, there’s an MCP server that gives it access to actual vulnerability data:

npx @ottersight/mcp

Add it to your Claude Code configuration:

{
  "mcpServers": {
    "ottersight": {
      "command": "npx",
      "args": ["@ottersight/mcp"]
    }
  }
}

Then ask Claude: “scan this project for vulnerable dependencies.”

Instead of guessing based on training data, Claude now queries real CVE databases and returns structured vulnerability information it can reason about.

Layer 3: Supply Chain Attacks

CVE scanners (including OtterSight) catch known vulnerabilities in legitimate packages. They don’t catch malicious packages pretending to be legitimate ones. For that, you need different tooling — Socket.dev or lockfile-lint are good starting points.

The full security stack for AI-assisted development looks like this:

Code review  → Claude's built-in security prompt
Known CVEs   → npx @ottersight/cli scan .
Supply chain → Socket.dev / lockfile-lint

Three layers, three tools. None of them covers all three.

The Irony

Claude Code has one of the most sophisticated AI security review systems in existence. Over 200 lines of carefully tuned instructions, with false-positive filtering, confidence scoring, and a methodology that would impress most security engineers.

And it explicitly punts on the attack vector that’s been responsible for some of the biggest breaches in recent years.

The fix is one command. The hard part is remembering to run it.

npx @ottersight/cli scan .

OtterSight CLI on GitHub — MIT licensed, open source, runs locally.