Dependency Risk Auditor

Every dependency is a hiring decision: you are taking on someone else's code, release habits, and security posture, usually without an interview. This skill audits a project's dependency tree for concentrated risk — abandonment, license traps, known vulnerabilities, supply-chain exposure, and sheer unjustified weight — and turns the findings into a ranked remediation plan instead of a wall of red.

When to use this skill

• Inheriting or acquiring a codebase and needing a risk picture fast
• Before a major release, compliance review, or security questionnaire
• The lockfile has not been meaningfully updated in over a year
• Deciding whether to adopt a new library or write the eighty lines yourself
• After a high-profile ecosystem incident, to check actual exposure

Workflow

1. Extract the full tree from the lockfile — direct and transitive, with exact versions. Note the direct-to-transitive ratio: risk you chose and risk you inherited get different treatments.
2. Run the ecosystem's vulnerability audit and record the findings — then keep going, because a clean audit means "no known issues in this one database," not "safe."
3. Score each direct dependency on five axes (0-2 each; 10 is maximum risk):
   • Maintenance: age of last release, issue response, bus factor of maintainers
   • Vulnerability history: current findings, and how fast past ones were fixed
   • License: compatibility with your distribution model; flag copyleft in proprietary contexts and source-available licenses pretending to be open
   • Blast radius: does it touch auth, crypto, serialization, networking, build scripts, or CI
   • Replaceability: depth of coupling; whether a standard-library or hundred-line alternative exists
4. Check supply-chain hygiene on the top-risk items: install-time scripts, bundled binaries, maintainer changes in the last year, typosquat-adjacent names, and whether the lockfile pins integrity hashes.
5. Find the unjustified weight: dependencies imported for one function, overlapping libraries doing the same job, and anything installable that nothing imports.
6. Rank remediations by risk reduction per unit of effort, not by scariness of headline. A patch bump that closes a real, reachable vulnerability outranks a philosophical migration.
7. Propose the policy ratchet so the audit is not a one-off: lockfile integrity enforced, a license allowlist in CI, an update cadence, and a written rule for adding new dependencies — who approves, against which checklist.

Output format

## Dependency audit: <project> — <date>

Tree: <n> direct, <m> transitive. Vulnerability findings: <x> (critical: <c>)

| Dependency | Version | Score /10 | Top risk | Recommendation | Effort |
|------------|---------|-----------|----------|----------------|--------|

### Do now (this week)
### Do next (this quarter)
### Accept (with reason and a revisit date)

Policy ratchet: <checks to add to CI>

Every "Accept" carries a reason and a date — silent acceptance is how audits expire.

Guardrails

• Never auto-apply major version upgrades from inside an audit; propose them with the breaking-change summary attached
• Distinguish "vulnerable dependency present" from "vulnerable code path reachable" — and treat unreachable as deprioritized, never as safe
• Do not recommend replacing a maintained dependency with bespoke code for anything cryptographic, timezone-shaped, or parser-shaped
• License analysis is input for counsel, not a legal opinion — the report says so explicitly
• Attribute transitive risk to the direct dependency that pulls it in; that is where your leverage is

Red flags worth escalating immediately

• Install-time scripts that fetch remote code
• A maintainer handle that changed hands recently, followed shortly by a release
• Pinned versions that no longer exist upstream
• Two lockfiles in the repo disagreeing about the same package
• A dependency of one — a single critical library maintained by a single account