Security

Dependency Vulnerability Auditor

Turn a raw dependency-audit tool's output into a prioritized, actionable list -- which CVEs are actually reachable from this codebase's usage, not just present in the lockfile.

When to use this

  • After running npm audit / pip-audit / cargo audit / similar, to prioritize the results.
  • Before a release, as part of a security gate.
  • Not a replacement for actually running the audit tool -- this skill interprets and prioritizes its output.

The skill file

Copy this verbatim. It's written in the SKILL.md format (YAML frontmatter + markdown instructions) that Claude Code, and increasingly other agent tools, read directly.

SKILL.md
---
name: dependency-vuln-auditor
description: Interpret dependency-audit tool output (npm audit, pip-audit, cargo audit, etc.) and prioritize findings by whether the vulnerable code path is actually reachable from how this codebase uses the package, not just by CVSS score. Use after running the audit tool.
---

# Dependency Vulnerability Auditor

A CVE in a transitive dependency you don't actually invoke is a different
risk than one in a function you call directly with user input. Prioritize
accordingly.

## Process

1. Run (or read the output of) the ecosystem's audit tool.
2. For each finding, check: is this a direct dependency or transitive?
   Direct dependencies are easier to patch and usually more exposed.
3. Check whether the codebase actually calls the vulnerable function/code
   path (grep for the import and usage), not just whether the package is
   installed. A vulnerability in a code path this project never exercises
   is much lower priority than one in active use.
4. Check whether a fixed version is available and how large the version
   jump is (patch vs. major -- major bumps need more testing before
   merging under time pressure).

## Output format

Table: package, CVE/advisory, severity, direct/transitive, reachable
(yes/no/unsure), fixed version available, and a recommended action
(upgrade now / upgrade with testing / low priority, track it / can't fix
yet -- note why).

Close with the two or three items that need action before the next
release, distinct from the full list.

Installing it elsewhere

The frontmatter/body split above is Claude Code's convention. Here's how to carry the same instructions into other tools:

Claude Code
.claude/skills/dependency-vuln-auditor/SKILL.md

Save the file below verbatim (frontmatter included) at that path, project-local or in ~/.claude/skills/ for a user-level skill. Claude Code loads the name/description pair to decide when to pull it in, or you invoke it directly as /dependency-vuln-auditor.

Cursor
.cursor/rules/dependency-vuln-auditor.mdc

Convert the YAML frontmatter to Cursor's rule format (description, globs, alwaysApply: false) and keep the markdown body as the rule content. Cursor surfaces it by description match, same idea as Claude Code's auto-load.

Codex CLI / Copilot
AGENTS.md

Codex CLI (and increasingly other agentic CLIs) read AGENTS.md at the repo root as always-on instructions. Paste the markdown body under a heading like ## {title}; for GitHub Copilot's coding agent, the equivalent file is .github/copilot-instructions.md.

Windsurf
.windsurfrules

Append the markdown body to .windsurfrules at the repo root. Windsurf treats the whole file as always-on context, so keep only the instructions you want applied on every request.

Where this goes wrong
  • Treating every CVSS-9+ finding as equally urgent regardless of reachability.
  • Recommending a major-version upgrade as a drive-by fix without flagging the testing burden that comes with it.
  • Ignoring transitive dependencies entirely -- some are just as exposed as direct ones.