| name | dependency-audit |
| description | Audit dependency health: outdated versions, unmaintained packages, known vulnerabilities, license issues, and bundle size impact. |
Dependency Audit
Overview
Dependencies are other people's code running in your application. Every dependency is a bet that the maintainer will keep it secure, compatible, and maintained. This skill provides a systematic process for evaluating that bet — checking for vulnerabilities, assessing maintenance health, analyzing bundle impact, and reviewing license compliance.
A dependency audit isn't a one-time event. Run it quarterly at minimum, and after any major version upgrade of your language or framework.
When to Use
- Quarterly dependency health review
- Before upgrading a framework or language version
- When adopting a new dependency (vet it before adding)
- After a security advisory for a dependency you use
- When bundle size or install time has grown unexpectedly
- Before a major release or security compliance review
When NOT to use: Routine version bumps with no breaking changes. Use your package manager's update command with tests for that.
Process
Step 1 — Inventory Dependencies
Get a complete picture of what you depend on, including transitive dependencies.
Commands by ecosystem:
| Ecosystem | List Direct | List All (incl. transitive) |
|---|
| npm | npm ls --depth=0 | npm ls --all |
| yarn | yarn list --depth=0 | yarn list |
| pnpm | pnpm list --depth=0 | pnpm list --depth=Infinity |
| pip | pip list | pip list (all are "direct" in pip) |
| mix (Elixir) | mix deps | mix deps.tree |
| cargo (Rust) | cargo metadata | cargo tree |
| go | go list -m all | go mod graph |
| Maven | mvn dependency:list | mvn dependency:tree |
Produce the inventory:
## Dependency Inventory
**Total direct dependencies**: [N]
**Total transitive dependencies**: [N]
**Last audit date**: [date]
### Direct Dependencies
| Package | Version | Purpose | Last Updated | License |
| ------- | --------- | --------------- | ------------ | --------- |
| [name] | [version] | [why we use it] | [date] | [license] |
Flag any dependency where you can't explain "why we use it" — it may be removable.
Step 2 — Check for Known Vulnerabilities
Run the package manager's built-in audit tool.
Commands:
| Ecosystem | Command | Notes |
|---|
| npm | npm audit | Add --production to skip dev deps |
| yarn | yarn audit | |
| pnpm | pnpm audit | |
| pip | pip-audit | Install: pip install pip-audit |
| mix | mix deps.audit + mix hex.audit | |
| cargo | cargo audit | Install: cargo install cargo-audit |
| go | govulncheck ./... | Install: go install golang.org/x/vuln/cmd/govulncheck |
| Maven | mvn org.owasp:dependency-check-maven:check | |
Document findings:
| Package | Vulnerability | Severity | CVE | Patched Version | Action |
|---|
| [name] | [title] | Critical/High/Medium/Low | [CVE-ID] | [version] | Update / Replace / Accept Risk |
Severity response times:
| Severity | Action Required Within |
|---|
| Critical | 24 hours |
| High | 1 week |
| Medium | 1 month |
| Low | Next quarterly audit |
Step 3 — Assess Maintenance Status
A dependency with no vulnerabilities today can become one tomorrow if it's unmaintained.
Health signals to check (per dependency):
| Signal | Healthy | Concerning | Unhealthy |
|---|
| Last commit | < 3 months | 3-12 months | > 12 months |
| Last release | < 6 months | 6-18 months | > 18 months |
| Open issues | Active triage | Growing backlog | Hundreds unanswered |
| Open PRs | Reviewed regularly | Stale PRs piling up | No PR reviews |
| Maintainer count | 2+ active | 1 active (bus factor) | 0 active |
| Downloads/month | Stable or growing | Declining | Expired |
| Funding | Sponsored / corporate | Community only | None |
Where to check:
- GitHub repository → Insights → Contributors, Pulse
- npm:
npm info <package> (last publish date)
- Snyk Advisor — package health score
- Socket.dev — supply chain risk
- deps.dev — Google's dependency analysis
Flag unmaintained packages:
## Maintenance Concerns
| Package | Last Release | Maintainers | Risk | Alternative |
| ------- | ------------ | ----------- | -------------- | ------------- |
| [name] | [date] | [count] | [High/Med/Low] | [replacement] |
Step 4 — Analyze Bundle Size Impact
For frontend projects, every dependency adds to what users download.
Tools:
| Tool | What It Shows | Command |
|---|
source-map-explorer | Treemap of bundle contents | npx source-map-explorer build/static/js/*.js |
webpack-bundle-analyzer | Interactive bundle visualization | Add plugin to webpack config |
bundlephobia.com | Size of any npm package | Search on website |
size-limit | CI-integrated size checking | npx size-limit |
import-cost | VS Code extension — inline size | Install extension |
Size budget guidelines:
| Metric | Target | Notes |
|---|
| Total JS bundle (gzipped) | < 200 KB | For initial page load |
| Single dependency | < 50 KB gzipped | Question anything larger |
| CSS bundle | < 50 KB gzipped | |
| Largest dependency | Document it | Know what dominates your bundle |
Identify heavy dependencies:
## Bundle Impact
| Package | Size (gzipped) | % of Bundle | Lighter Alternative |
| ------- | -------------- | ----------- | ----------------------- |
| [name] | [size] | [%] | [alternative or "none"] |
Step 5 — Review Licenses
License incompatibility can force you to open-source your code or remove a dependency.
License compatibility (for proprietary projects):
| License | Commercial Use | Conditions | Risk |
|---|
| MIT | Yes | Attribution | None |
| Apache 2.0 | Yes | Attribution + patent grant | None |
| BSD 2/3-Clause | Yes | Attribution | None |
| ISC | Yes | Attribution | None |
| MPL 2.0 | Yes | Modified files must be shared | Low |
| LGPL 2.1/3.0 | Yes (with care) | Dynamic linking OK, static may require sharing | Medium |
| GPL 2.0/3.0 | Restricted | Derivative work must use GPL | High |
| AGPL 3.0 | Restricted | Network use triggers sharing requirement | High |
| SSPL | Restricted | Service use triggers sharing requirement | High |
| Unlicensed / No License | No | No permission granted | Critical |
Commands to check:
| Ecosystem | Command |
|---|
| npm | npx license-checker --summary |
| pip | pip-licenses |
| mix | mix licenses (with hex_licenses) |
| cargo | cargo license |
| go | go-licenses check ./... |
Flag problematic licenses:
## License Concerns
| Package | License | Risk | Action |
| ------- | --------- | ------- | --------------------------------- |
| [name] | [license] | [level] | [Replace / Accept / Legal review] |
Step 6 — Create Remediation Plan
Combine all findings into an actionable plan.
## Dependency Audit Report
**Project**: [Name]
**Date**: [Date]
**Auditor**: [Name]
### Summary
| Category | Issues Found | Critical | Action Required |
| --------------- | ------------- | -------- | ---------------------- |
| Vulnerabilities | [N] | [N] | Update / Replace |
| Unmaintained | [N] | [N] | Find alternatives |
| Bundle impact | [N] oversized | — | Optimize / Replace |
| License issues | [N] | [N] | Replace / Legal review |
### Prioritized Actions
| Priority | Action | Package | Risk if Ignored | Effort |
| -------- | --------------------------------------------- | ------- | -------------------- | ------ |
| P1 | Patch critical CVE | [name] | Exploitation | S |
| P2 | Replace unmaintained package | [name] | Future vulnerability | M |
| P3 | Swap heavy dependency for lighter alternative | [name] | Bundle bloat | M |
| P4 | Resolve license concern | [name] | Legal risk | S |
### Packages to Remove
| Package | Reason | Replacement |
| ------- | ---------------------------------------------- | ------------------------------ |
| [name] | [unused / duplicate / replaceable with stdlib] | [replacement or "none needed"] |
### Next Audit
Scheduled: [date — within 90 days]
Common Rationalizations
| Rationalization | Reality |
|---|
| "It's just a dev dependency, vulnerabilities don't matter" | Supply chain attacks target dev tools (build scripts, linters). Dev dependencies run on your machine with your credentials. |
| "We pin versions so we're safe" | Pinning prevents unexpected updates but also prevents security patches. You still need to audit and update deliberately. |
| "It's a popular package, it must be maintained" | Popular packages get abandoned too. Check the signals, not the star count. |
| "We need this dependency — there's no alternative" | Almost every dependency has alternatives. If there truly isn't one, consider inlining the specific functionality you need. |
| "License compliance is a legal problem, not an engineering one" | Engineers choose dependencies. If you add a GPL library to a proprietary project, legal can't fix that without a code change. |
Red Flags
- Dependencies with known critical vulnerabilities that haven't been patched
- More than 3 dependencies with no commit in the past 12 months
- No lockfile committed to version control
- Transitive dependency count is 10x+ direct dependency count
- A dependency with a single maintainer and no corporate backing
- Packages with no license file (not MIT/Apache — literally no license)
- Bundle size has grown > 20% since last audit with no new features
- Dependencies pulled from unofficial registries or git URLs
Verification
