Audits third-party dependencies for exploitable CVEs, abandonment, license exposure, and supply-chain hygiene, and delivers a ranked findings report with a remediation order.
Audits third-party dependencies for exploitable CVEs, abandonment, license exposure, and supply-chain hygiene, and delivers a ranked findings report with a remediation order. Use when someone asks "is this package safe to add", "audit our dependencies", "npm audit is screaming, what actually matters", "can we use this GPL library", or is preparing a security review or vendor questionnaire. Do NOT use for triaging vulnerabilities in first-party code or a full CVE queue - use vulnerability-triage instead; for reviewing the code you wrote for security flaws - use secure-code-review instead; for how secrets are stored and rotated - use secrets-hygiene instead; for assembling compliance evidence - use soc2-evidence-helper instead.This is the skill's description: the text your AI reads to decide when the skill applies.
dependency-risk-audit/SKILL.md
---
name: Dependency Risk Audit
description: Audits third-party dependencies for exploitable CVEs, abandonment, license exposure, and supply-chain hygiene, and delivers a ranked findings report with a remediation order. Use when someone asks "is this package safe to add", "audit our dependencies", "npm audit is screaming, what actually matters", "can we use this GPL library", or is preparing a security review or vendor questionnaire. Do NOT use for triaging vulnerabilities in first-party code or a full CVE queue - use vulnerability-triage instead; for reviewing the code you wrote for security flaws - use secure-code-review instead; for how secrets are stored and rotated - use secrets-hygiene instead; for assembling compliance evidence - use soc2-evidence-helper instead.
---
# Dependency Risk Audit
Third-party packages are the most common source of supply-chain compromise and known-vulnerability exploitation; treat dependency selection as a security decision, not a convenience one. The costly failure this skill prevents is on both ends: shipping a reachable critical CVE because the audit output was noise nobody read, and burning a sprint patching findings in code paths that can never execute.
## Operating procedure
### Step 1: gather inputs
Collect (label guesses as guesses):
1. Ecosystem and manifest/lockfile (package.json + lockfile, requirements/poetry, Gemfile.lock, go.mod).
2. Deployment context: server-side, client-side, CLI-only, or build-time only - this decides reachability.
3. License posture: proprietary/commercial code, or open source (decides copyleft tolerance).
4. Whether this is a point decision (one new package) or a full audit (whole tree).
### Step 2: run the native audit and triage for reachability
Run the ecosystem's native tool first: `npm audit`, `pip-audit`, `bundle audit`, `govulncheck` (which does reachability analysis natively - trust its "not called" verdicts). For each finding:
- Confirm exploitability in context - a CVE in a CLI-only code path of a server-side lib may not be reachable. A dev-only dependency (test runner, linter) is almost never exploitable in production, but IS in scope for install-time attacks.… load the full skill through Skill MeClick to play with sound.