Security Audit

Intelligently analyze npm audit results. Distinguishes real threats from transitive dependency noise and recommends specific actions.

When to Use

• After make audit shows vulnerabilities
• Before deploying to production
• When updating dependencies
• Periodic security check (integrated into /preflight)

Instructions

1. Run Audit

pnpm audit --json 2>/dev/null || true

If no package.json exists, report "No Node.js project found" and exit.

2. Parse Each Vulnerability

For each vulnerability, determine:

A. Direct vs Transitive

Look at the via and effects fields:

• Direct: Your package.json depends on the vulnerable package
• Transitive: A dependency of a dependency is vulnerable

# Check if package is a direct dependency
grep -q '"<package-name>"' package.json && echo "DIRECT" || echo "TRANSITIVE"

B. Production vs Dev

# Check if it's a dev dependency
grep -A5 '"devDependencies"' package.json | grep -q '"<package-name>"' && echo "DEV" || echo "PROD"

For transitive deps, trace up to find the root:

pnpm why <vulnerable-package>

C. Exploitability

Consider:

• Is the vulnerable code path actually used?
• JWT vulnerabilities don't matter if you use Clerk
• XSS in markdown parser doesn't matter if you sanitize output
• Server-only packages aren't exposed to client attacks

3. Check for Existing Overrides

Before recommending fixes, check if overrides are already in place:

# Check package.json for pnpm overrides
grep -A20 '"pnpm"' package.json | grep -A15 '"overrides"'

Note: This checks pnpm-style overrides only. npm uses "overrides" at root level, yarn uses "resolutions".

If an override exists for the vulnerable package:

• Check if the override version is >= patched version
• If yes: vulnerability should be resolved (verify with pnpm list <package>)
• If no: override exists but needs version bump

4. Check for Fixes

For each vulnerability:

# Check if parent package has update
pnpm outdated <parent-package> 2>/dev/null

# Check latest version
pnpm info <parent-package> version

5. Classify

Category	Criteria	Action
Critical	Direct + Production + Exploitable	Fix immediately
High	Direct + Production	Update when convenient
Medium	Transitive + Production	Monitor, check for parent updates
Low	Dev dependency only	Can ignore, update eventually
Overridden	Has pnpm override >= patched version	Verify resolved, no action needed
Noise	Transitive + Dev + Not exploitable	Ignore

6. Recommend Actions

For each non-noise vulnerability:

If direct dependency:

pnpm update <package>@latest

If transitive (parent has fix):

pnpm update <parent-package>@latest

If transitive (no fix available):

• Check GitHub issues on parent package for timeline:

  gh search issues --repo <owner/repo> "<vulnerable-package>" --state open
  

• Consider override (last resort):

// package.json
"pnpm": {
  "overrides": {
    "<vulnerable-package>": ">=<fixed-version>"
  }
}

If not exploitable in your context:

• Document why it's not a risk
• Revisit on next audit

Output Format

## Security Audit Report

**Summary:** X vulnerabilities found, Y actionable

### Critical (fix now)
- **<package>** (<severity>) - <vulnerability>
  - Type: Direct / Production
  - Fix: `pnpm update <package>@<version>`

### Should Fix
- **<package>** (<severity>) - <vulnerability>
  - Type: Transitive via `<parent>`
  - Fix: `pnpm update <parent>@<version>`

### Monitor
- **<package>** (<severity>) - <vulnerability>
  - Type: Transitive via `<parent>`
  - Status: No fix available, tracked in <github-issue-link>

### Already Resolved (via override)
- **<package>** (<severity>) - <vulnerability>
  - Override: `"<package>": ">= <version>"` in package.json
  - Verified: `pnpm list <package>` shows <resolved-version>

### Noise (can ignore)
- **<package>** (<severity>) - <vulnerability>
  - Reason: Dev dependency only / Not exploitable because <reason>

### Recommended Actions
1. {specific command to run}
2. {specific command to run}

### Next Audit
Run `/audit` again after updates to verify fixes.

Common Scenarios

"Vulnerability in Prisma's dev tools"

Prisma bundles dev tools (Studio) with their own dependencies. These don't affect your production app.

• Verdict: Noise (dev tooling, not in your code path)

"Vulnerability in testing framework"

Jest, Vitest, Playwright vulnerabilities are dev-only.

• Verdict: Low priority (update when convenient, doesn't affect prod)

"JWT vulnerability but using Clerk"

If you don't use the vulnerable JWT code path, it's not exploitable.

• Verdict: Noise (not exploitable in your context)

"XSS in markdown parser"

Only matters if you render untrusted markdown without sanitization.

• Verdict: Check if you sanitize. If yes, noise. If no, critical.

Notes

• pnpm audit returns exit code 1 when vulnerabilities exist (expected)
• Override caveat: pnpm audit may still report vulnerabilities even with overrides, because it checks declared versions in lockfile metadata. Verify actual resolution with pnpm list <package>
• Some packages will never be fixed (abandoned) - consider alternatives
• Overrides can break things - use sparingly and test thoroughly
• After adding/changing overrides, run pnpm install to apply