Back to list
cerico

audit

by cerico

https://macfair.io37.ch

0🍴 0📅 Jan 24, 2026

SKILL.md


name: audit description: Analyze npm audit results, identify actionable fixes vs noise, and recommend specific actions

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

CategoryCriteriaAction
CriticalDirect + Production + ExploitableFix immediately
HighDirect + ProductionUpdate when convenient
MediumTransitive + ProductionMonitor, check for parent updates
LowDev dependency onlyCan ignore, update eventually
OverriddenHas pnpm override >= patched versionVerify resolved, no action needed
NoiseTransitive + Dev + Not exploitableIgnore

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

Score

Total Score

55/100

Based on repository quality metrics

SKILL.md

SKILL.mdファイルが含まれている

+20
LICENSE

ライセンスが設定されている

0/10
説明文

100文字以上の説明がある

0/10
人気

GitHub Stars 100以上

0/15
最近の活動

1ヶ月以内に更新

+10
フォーク

10回以上フォークされている

0/5
Issue管理

オープンIssueが50未満

+5
言語

プログラミング言語が設定されている

+5
タグ

1つ以上のタグが設定されている

+5

Reviews

💬

Reviews coming soon