# Dependency Audit

> Audit project dependencies — version currency, known vulnerabilities (CVEs), license compliance, unused dependencies, size impact, and upgrade recommendations. TRIGGER when: user says /dependency-audit, asks to audit dependencies, check for vulnerabilities, review package health, or assess dependency risk.

- Skill: `ashutoshsrivastava17/dependency-audit` (Agent Skill)
- Install (CLI): `npx skillmds@latest add ashutoshsrivastava17/dependency-audit`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ashutoshsrivastava17/dependency-audit/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: ashutoshsrivastava17 (https://skillmd.com/u/ashutoshsrivastava17)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/ashutoshsrivastava17/dependency-audit

---


# Dependency Audit

You are a senior security and platform engineer performing a thorough audit of project dependencies. Identify risks, vulnerabilities, licensing issues, and maintenance concerns, then provide prioritized upgrade recommendations.

## Process

### Step 1: Identify the Ecosystem and Manifest

Determine:
- What language/ecosystem? (Node.js, Python, Go, Rust, Java, Ruby, .NET)
- Where is the dependency manifest? (package.json, requirements.txt, go.mod, Cargo.toml, pom.xml, Gemfile)
- Is there a lockfile? (package-lock.json, yarn.lock, poetry.lock, Cargo.lock, go.sum)
- Are there multiple dependency manifests (monorepo)?
- What is the deployment target? (serverless, containers, edge — affects size sensitivity)

**Manifest file reference:**

| Ecosystem | Manifest | Lockfile | Audit Tool |
|-----------|----------|----------|------------|
| Node.js (npm) | package.json | package-lock.json | `npm audit` |
| Node.js (yarn) | package.json | yarn.lock | `yarn audit` |
| Node.js (pnpm) | package.json | pnpm-lock.yaml | `pnpm audit` |
| Python (pip) | requirements.txt | N/A | `pip-audit`, `safety` |
| Python (poetry) | pyproject.toml | poetry.lock | `pip-audit`, `safety` |
| Go | go.mod | go.sum | `govulncheck` |
| Rust | Cargo.toml | Cargo.lock | `cargo audit` |
| Java (Maven) | pom.xml | N/A | `mvn dependency-check:check` |
| Java (Gradle) | build.gradle | N/A | OWASP dependency-check plugin |
| Ruby | Gemfile | Gemfile.lock | `bundle audit` |
| .NET | *.csproj | packages.lock.json | `dotnet list package --vulnerable` |

### Step 2: Version Currency Assessment

For each dependency, evaluate how current it is:

**Currency classification:**

| Status | Definition | Risk | Action |
|--------|-----------|------|--------|
| Current | On latest stable version | None | No action needed |
| Minor behind | 1-2 minor versions behind latest | Low | Upgrade at convenience |
| Major behind | 1+ major versions behind latest | Medium | Plan upgrade, check breaking changes |
| Severely outdated | 2+ major versions behind or >2 years stale | High | Prioritize upgrade, check for EOL |
| End of Life (EOL) | No longer maintained or receiving security patches | Critical | Upgrade or replace immediately |

**Generate a currency report table:**

| Package | Current Version | Latest Version | Versions Behind | Last Published | Status |
|---------|----------------|----------------|----------------|----------------|--------|
| *package-name* | *installed* | *latest* | *count* | *date* | Current / Minor behind / Major behind / EOL |

### Step 3: Vulnerability Scan (CVEs)

Check all dependencies against known vulnerability databases:

**Vulnerability databases to check:**
- National Vulnerability Database (NVD)
- GitHub Advisory Database (GHSA)
- OSV (Open Source Vulnerability database)
- Snyk Vulnerability DB
- RustSec Advisory Database (Rust)
- PyPI Advisory Database (Python)

**Severity classification (CVSS):**

| Severity | CVSS Score | SLA to Patch | Example |
|----------|-----------|-------------|---------|
| Critical | 9.0 - 10.0 | 24-48 hours | Remote code execution, auth bypass |
| High | 7.0 - 8.9 | 1 week | Privilege escalation, data exposure |
| Medium | 4.0 - 6.9 | 1 month | Denial of service, information disclosure |
| Low | 0.1 - 3.9 | Next release cycle | Minor information leak, theoretical attack |

**Generate a vulnerability report table:**

| Package | Version | CVE ID | Severity | CVSS | Description | Fixed In | Exploitable |
|---------|---------|--------|----------|------|-------------|----------|-------------|
| *name* | *ver* | *CVE-XXXX-XXXXX* | Critical/High/Medium/Low | *score* | *brief description* | *version* | Yes / No / Unknown |

### Step 4: License Compliance

Audit every dependency's license for compatibility with your project:

**License risk classification:**

| Risk Level | Licenses | Concern |
|------------|----------|---------|
| Permissive (safe) | MIT, BSD-2, BSD-3, ISC, Apache-2.0, Unlicense | No restrictions on commercial use |
| Weak copyleft (caution) | LGPL-2.1, LGPL-3.0, MPL-2.0, EPL-2.0 | Modifications to the library must be open-sourced; your code is safe if dynamically linked |
| Strong copyleft (risk) | GPL-2.0, GPL-3.0, AGPL-3.0 | Your entire project may need to be open-sourced if you distribute it |
| No license | N/A | Legally ambiguous; all rights reserved by default. Avoid or seek explicit permission |
| Custom / Unknown | Various | Requires legal review before use |

**License audit checklist:**
- [ ] Every dependency has a declared license
- [ ] No GPL/AGPL dependencies in proprietary/closed-source projects
- [ ] LGPL dependencies are dynamically linked (not statically bundled)
- [ ] License obligations (attribution, notice files) are met in distribution
- [ ] Transitive dependencies (dependencies of dependencies) are also checked
- [ ] Company-specific banned license list has been consulted

**Generate a license report table:**

| Package | Version | License | Risk Level | Compatible | Notes |
|---------|---------|---------|------------|------------|-------|
| *name* | *ver* | *SPDX ID* | Permissive / Weak copyleft / Strong copyleft / None | Yes / No / Review | *any notes* |

### Step 5: Unused and Redundant Dependencies

Identify dependencies that can be removed:

**Detection methods:**

| Method | Tool | Ecosystem |
|--------|------|-----------|
| Static analysis | `depcheck` | Node.js |
| Static analysis | `deptry` | Python |
| Import scanning | `unused` | Go |
| Dead code analysis | `cargo-udeps` | Rust |
| Manual review | grep for import/require statements | Any |

**Categories of removable dependencies:**
- [ ] **Unused** — Declared but never imported or referenced in code
- [ ] **Redundant** — Multiple packages providing the same functionality (e.g., `lodash` + `underscore`)
- [ ] **Built-in replacements** — Packages that duplicate standard library functionality (e.g., `is-even`, `left-pad`, `path-is-absolute`)
- [ ] **Dev-in-prod** — Development-only dependencies incorrectly listed as production dependencies
- [ ] **Transitive duplicates** — Multiple versions of the same package in the dependency tree

### Step 6: Size Impact Analysis

Evaluate the bundle and install size impact of dependencies:

**Size metrics to evaluate:**

| Metric | Description | Tool |
|--------|-------------|------|
| Install size | Total disk space after install | `npm pack --dry-run`, `du -sh node_modules/pkg` |
| Bundle size (minified) | Size after bundling and minification | bundlephobia.com, `size-limit` |
| Bundle size (gzipped) | Size after compression (actual transfer size) | bundlephobia.com, `size-limit` |
| Tree-shakeable | Can unused exports be eliminated | Check for ESM support, `sideEffects: false` |
| Dependency count | Number of transitive dependencies pulled in | `npm ls --all`, `pipdeptree` |

**Size concern thresholds (frontend/browser context):**

| Concern Level | Single Package (gzip) | Total Bundle (gzip) |
|---------------|----------------------|---------------------|
| Acceptable | < 10 KB | < 200 KB |
| Review | 10-50 KB | 200-500 KB |
| Concerning | 50-100 KB | 500 KB - 1 MB |
| Excessive | > 100 KB | > 1 MB |

**Generate a size impact table (for top offenders):**

| Package | Install Size | Bundle Size (gzip) | Transitive Deps | Tree-Shakeable | Lighter Alternative |
|---------|-------------|-------------------|-----------------|----------------|-------------------|
| *name* | *size* | *size* | *count* | Yes / No | *alternative or N/A* |

## Output Format

Present the audit as:

```
## Dependency Audit: {Project Name}

### Summary
- Total dependencies: [count] (production: [N], development: [N])
- Vulnerabilities: [N critical, N high, N medium, N low]
- Outdated packages: [N severely outdated, N major behind, N minor behind]
- License issues: [N packages require review]
- Unused dependencies: [N packages can be removed]
- Estimated removable size: [size]

### Critical Actions (do immediately)
1. [Vulnerability fix or EOL replacement]
2. ...

### High Priority (this sprint)
1. [Major version upgrades, license issues]
2. ...

### Medium Priority (this quarter)
1. [Minor upgrades, unused dependency removal]
2. ...

### Low Priority (backlog)
1. [Nice-to-have optimizations]
2. ...

### Detailed Reports
- Version currency table
- Vulnerability table
- License compliance table
- Unused dependencies list
- Size impact analysis
```

## Quality Checklist

Before delivering the audit report, verify:

- [ ] Every production dependency has been checked for vulnerabilities
- [ ] Transitive dependencies are included in the vulnerability scan (not just direct)
- [ ] Version currency is assessed against the latest stable release (not pre-release)
- [ ] License check covers transitive dependencies, not just direct
- [ ] Unused dependency analysis has been validated (no false positives that would break the build)
- [ ] Size analysis is relevant to the deployment context (skip for backend-only projects)
- [ ] Upgrade recommendations include specific target versions
- [ ] Breaking changes in recommended upgrades are documented
- [ ] Critical vulnerabilities have clear, actionable remediation steps
- [ ] The report distinguishes between production and development dependencies

## Edge Cases

Consider and address these scenarios:

- **Monorepos** — Audit each workspace/package independently. Shared dependencies may have version conflicts across workspaces. Use tools that support workspace-aware scanning.
- **Private/internal packages** — Internal packages won't appear in public vulnerability databases. Flag them separately and recommend internal security review.
- **Pinned versions** — If the project pins exact versions (no ranges), check whether the pin is intentional (stability) or accidental (stale lockfile).
- **Forked dependencies** — If the project uses a fork, the fork may not receive upstream security patches. Track the upstream version and compare.
- **Optional/peer dependencies** — These may not be installed in all environments. Audit them based on which optional features are actually used.
- **Build-time only dependencies** — Webpack plugins, Babel presets, and similar build tools still pose supply chain risk even though they don't ship to production. Include them in vulnerability scans.
- **Transitive vulnerability with no direct upgrade path** — When a vulnerability exists in a transitive dependency and the direct dependency hasn't released a fix, document the workaround (override/resolution, fork, or replace the parent package).
- **License changes between versions** — A package may change its license in a new version. Verify the license of the specific installed version, not just the latest.
- **Typosquatting and supply chain attacks** — Check for packages with suspicious names similar to popular packages. Verify package provenance and publisher reputation.
- **Native/binary dependencies** — Packages with native bindings (node-gyp, Cython extensions) introduce platform-specific risks and may require separate security review.