The False Positive Trap

A concrete example

Take the list from module 3. The agent flags a critical CVE on a package present in pnpm-lock.yaml. Digging in, it turns out this package is only a transitive dependency of a build tool (a bundler, a linter) — it's never imported or executed by the application code, let alone in production.

The agent didn't lie: the CVE is real, the package is genuinely present. But its implicit conclusion — "this project is exposed" — is false.

Why this is a real trap

This kind of false positive is particularly deceptive because it looks legitimate: "critical" severity, a real package, a documented CVE. Nothing at first glance sets it apart from a genuine emergency.

The cost isn't zero, though:

• Wasted time on a fix that changes nothing about the actual risk.
• A real emergency delayed while the false positive gets handled.
• Eroded trust in the agent, if this happens too often without a way to catch it.

What to take away

A vulnerable package's presence in the lockfile is only a starting signal, not a conclusion. What's left to know is whether that code is actually executed, in a context that exposes us — the next module teaches how to check that, methodically.