Dependency Audit Skill

Activates when a developer asks about dependency safety, freshness, or licensing. Runs the right audit tool for the project's package manager, parses the output, and translates "47 vulnerabilities found" into "here are the 3 you actually need to fix and how."

When it triggers

"Audit dependencies / packages"
"Check for vulnerabilities"
"Are my dependencies up to date?"
"What needs upgrading?"
"License audit / compliance check"
After a security scan flags issues

Why a skill

Raw audit tool output is noisy. npm audit returns 200 vulnerabilities, most of which are transitive, low-severity, or unfixable. Developers tune them out. This skill cuts through the noise: what's actually exploitable, what's actually fixable, and in what order.

Installation

Copy this skill folder to ~/.claude/skills/dependency-audit/
Restart Claude Code
Try: "Audit my dependencies"

SKILL.md content

---
name: dependency-audit
description: |
  Use this skill when the user wants to audit dependencies for security
  vulnerabilities, outdated versions, or license issues. Triggers on:
  "audit dependencies / packages", "check for vulnerabilities", "are my deps
  up to date", "what needs upgrading", "license audit", "security scan results".

  Also use when CI flags dependency issues and the user pastes the output
  asking for help.

  Do NOT use for: writing code that uses a specific library, or upgrading a
  single specific package (just bump the version).
---

# Dependency Audit

You translate noisy audit-tool output into actionable triage. You distinguish
real risks from theatre, fixable from unfixable, and explain what to do in
what order.

## Process when activated

### Step 1: Identify the package manager

Detect by looking for files in the project root:
- `package.json` + `package-lock.json` → npm
- `package.json` + `pnpm-lock.yaml` → pnpm
- `package.json` + `yarn.lock` → Yarn
- `pyproject.toml` + `poetry.lock` → Poetry
- `pyproject.toml` + `uv.lock` → uv
- `requirements.txt` → pip
- `pom.xml` → Maven
- `build.gradle` / `build.gradle.kts` → Gradle
- `Cargo.toml` → Cargo
- `go.mod` → Go modules
- `Gemfile.lock` → Bundler

If multiple lockfiles exist (monorepo), ask which to focus on.

### Step 2: Run the right audit command

| Tool | Audit command |
|------|---------------|
| npm | `npm audit --json` |
| pnpm | `pnpm audit --json` |
| Yarn (Berry) | `yarn npm audit --json` |
| Poetry | `poetry check` + `pip-audit` |
| uv | `uv pip check` + `pip-audit` |
| pip | `pip-audit` |
| Maven | `mvn dependency-check:check` (OWASP) |
| Gradle | `./gradlew dependencyCheckAnalyze` |
| Cargo | `cargo audit` |
| Go | `govulncheck ./...` |
| Bundler | `bundle audit` |

DON'T just run it and dump the output. Parse it. Categorize. Triage.

### Step 3: Categorize findings

For each vulnerability, classify:

#### Severity (use the tool's CVSS-mapped severity)
- **Critical** (CVSS 9.0-10.0)
- **High** (CVSS 7.0-8.9)
- **Medium** (CVSS 4.0-6.9)
- **Low** (CVSS 0.1-3.9)

#### Exploitability in THIS project

Critical questions to ask about each finding:
1. **Is this dependency actually used at runtime?**
   - Dev-only deps (testing, build tools) have lower real-world risk
2. **Does the vulnerable code path get exercised?**
   - A `prototype pollution` vuln in a JSON parser only matters if you parse
     untrusted JSON
3. **Is the dependency direct or transitive?**
   - Transitive vulns may not be fixable without upstream patches
   - Direct deps are easy to upgrade

#### Fixability
- **Direct fix available** — bump the package
- **Indirect fix** — upstream package needs to bump first
- **No fix yet** — vulnerability disclosed but no patched version
- **Breaking change required** — fix is in a major version with API breaks

### Step 4: Triage

Output in this order:

#### 🔴 Fix immediately (Critical / High + exploitable + fixable)
For each:
- Package name and current version
- Vulnerable to: [CVE or summary]
- Risk in this project: [specific to your code]
- Fix: `pnpm up <package>@<version>` (or equivalent command)
- Estimated effort: [trivial / small / medium / large]

#### 🟡 Plan to fix (Medium severity OR breaking-change fix)
Same format, lower priority.

#### 🟢 Track (Low severity, unfixable, or low-exploitability)
Brief list:
- Package, severity, why deferred
- "Recheck monthly" or "wait for upstream fix"

#### 🚫 Ignore (false positives, dev-only, sandboxed)
Briefly note why.

#### 📦 Outdated but not vulnerable

If the user also wants freshness info, list the top 5-10 packages most
out-of-date. For each:
- Current → Latest
- Days behind
- Likely upgrade complexity (patch / minor / major)
- Highlight any majors that are >12 months behind (real upgrade pain ahead)

#### 📜 License findings

If the project has license-sensitive code (commercial product, regulated
industry):

Flag any:
- GPL/AGPL transitively pulled in (copyleft)
- Unlicensed packages
- License changes since last audit

For each flagged license, note:
- The package
- Its license
- Whether it's allowed by [the project's policy if known]
- Action: review/replace/accept

### Step 5: Generate the upgrade commands

Provide a single block the user can review and run:

```bash
# Critical/High fixes (direct upgrades)
pnpm up package-a@1.2.3 package-b@4.5.6

# Then re-run the audit to verify
pnpm audit

If multiple commands across categories, group them clearly.

If a fix requires a major version bump, NOTE separately:

"package-c needs a major bump (1.x → 2.x). Likely API breaks. Suggest:

Read changelog: [URL]

Run upgrade in a feature branch

Run tests, fix breaks, then merge"

Step 6: What you don't do

Don't run upgrade commands without confirmation. Show the plan, get approval, then run if asked.
Don't pretend a vulnerability is exploitable when it isn't. Be honest about which findings are theatre.
Don't recommend tools that aren't in the project's package manager ecosystem. Don't suggest snyk/dependabot if they're using bare npm audit.
Don't ignore the lockfile. Always pin to specific versions, not ranges, when fixing security issues.

Special cases

Monorepos

For monorepos with multiple package.jsons:

Run audit at the workspace root (e.g., pnpm audit -r)
Group findings by workspace
Same package vulnerable in 5 workspaces is one fix at the root if hoisted

Yarn 1 vs Yarn Berry

These have different audit commands:

Yarn 1: yarn audit
Yarn Berry: yarn npm audit

Detect by Yarn version: yarn --version.

Old projects with hundreds of vulnerabilities

If the audit returns 100+ findings, don't try to triage all of them:

"This project has 247 audit findings. That's too many to triage individually. Focused approach:

Filter to Critical/High only ([N] findings)

Filter to direct dependencies only ([M] findings)

Tackle those first

The rest are likely transitive low-severity issues. Address them via regular dependency hygiene (Dependabot, Renovate, monthly upgrade days) rather than a one-time audit."

Vulnerabilities in transitive dependencies

Common pattern: package X depends on Y depends on Z, and Z is vulnerable.

Options:

Wait for Y to bump Z (often the right call)
Use a resolution to override Z directly (npm overrides, pnpm overrides, Yarn resolutions)
Replace X with an alternative

Show all three, note the trade-off:

"Override Z directly = quick fix but you're now responsible for tracking Z's updates. Wait for Y = no work but vulnerability persists."

Zero-day in a critical dep

If a CVE just dropped on something like lodash or react:

Confirm the CVE is real (not a typosquat from a junk advisory)
Check the patched version is published and not just announced
Pin to the patched version, not a range
After upgrade, re-run audit AND tests

Anti-patterns to avoid

Treating every CVE as urgent (most aren't)
Treating vulnerabilities in dev deps as urgent (they usually aren't)
Auto-running npm audit fix --force (can break things)
Ignoring the actual CVE description ("CVSS 9.8" without reading why)
Bumping major versions to fix a low-severity issue (cure > disease)
Adding new tools when the language's built-in audit is sufficient


## Pairing with other skills

- **Code Reviewer** flags suspicious-looking deps in PRs; this skill audits the full set
- **Documentation Skill** can update CHANGELOG with security fixes after
- For Python projects, pair with `pip-audit` and `bandit` (separate concern: code-level static analysis)

## Tips

- Run audits weekly, not just before releases. Vulnerabilities disclose continuously.
- Combine with Dependabot or Renovate for ongoing maintenance — those tools open PRs proactively, this skill handles ad-hoc deep dives
- Keep an "exception list" for known-acceptable findings so you can see what's NEW since last audit
- For regulated industries (HIPAA, PCI), license audits matter as much as vulnerability audits

## Limitations

- Audit tools only catch *known* vulnerabilities — zero-days won't show up
- The skill doesn't actually validate exploitability in your code (that's a deeper SAST/DAST analysis)
- For deep supply-chain security (typosquatting, malicious packages), you need additional tooling like Socket.dev or Snyk
- License analysis depends on package metadata accuracy, which varies