Verifying Real Impact, Not Just Presence

The method, in three checks

Done in order, they're enough to turn a raw alert into a reliable verdict:

1. Is the vulnerable code imported anywhere? Searching the source for the package name or the affected function often answers this on its own.
2. Is that code path reached in production? A dependency can be imported only in a build script, a test, or a dev tool — never in the code that actually runs for the user.
3. Is the package direct or transitive — and how deep? A transitive dependency of a build tool's dependency's dependency is a much weaker signal than a direct production dependency.

Example

# Does the package actually show up in application code usage?
grep -rn "package-name" src/ --include="*.ts" --include="*.tsx"

# What does its dependency chain look like?
pnpm why package-name

If the search turns up nothing in src/, and pnpm why shows the package only arrives through a build tool that never runs in production, the verdict is clear: present, but not exposed.

The final verdict

By the end of this check, every CVE from the initial list gets a simple binary verdict: exposed or not exposed. Only "exposed" CVEs are worth carrying into the next module — evaluating a fix.