Dependency Audit

Reference Files

references/license-compatibility.md

references/health-metrics.md

references/bloat-detection.md

references/cve-sources.md

Prerequisites

• Access to the project's dependency files (

  pyproject.toml

  ,

  requirements.txt

  ,

  package.json

  ,

  Cargo.toml

  ,

  go.mod

  )
• Lock file (for exact versions and transitive dependencies)
• Project license (to determine compatibility requirements)

Workflow

Phase 1: Parse Dependency Tree

1. Direct dependencies — Packages explicitly declared in the project.
2. Transitive dependencies — Dependencies of dependencies. Often 10-50x the direct count.
3. Version constraints — Pinned (

   ==1.2.3

   ), ranged (

   >=1.0,<2.0

   ), or floating (

   *

   ).
4. Development vs production — Separate dev/test dependencies from production.

• Python:

  uv pip list

  ,

  pip-audit

  ,

  pipdeptree

• Node.js:

  npm list --all

  ,

  npm audit

• Rust:

  cargo tree

  ,

  cargo audit

Phase 2: Audit Licenses

1. Identify the license — Check package metadata, LICENSE file, pyproject.toml.
2. Classify compatibility — Against the project's own license:

   License	Commercial OK	Copyleft	Risk Level
   MIT, BSD, ISC, Apache 2.0	Yes	No	Low
   LGPL	With care	Weak	Medium
   GPL-2.0, GPL-3.0	No (unless GPL project)	Strong	High
   AGPL	No (unless AGPL project)	Strong + network	Critical
   Unknown	Cannot determine	Unknown	Critical

3. Flag issues — Copyleft licenses in proprietary projects, unknown licenses, license changes between versions.

Phase 3: Assess Maintenance Health

Phase 4: Check Security

1. Known CVEs — Check against advisory databases:
   • Python:

     pip-audit

     , PyPI advisory database
   • Node.js:

     npm audit

     , GitHub Advisory Database
   • General: NVD (National Vulnerability Database)
2. Severity classification — CVSS score interpretation:

   CVSS Score	Severity	Action
   9.0-10.0	Critical	Upgrade immediately
   7.0-8.9	High	Upgrade within days
   4.0-6.9	Medium	Upgrade within weeks
   0.1-3.9	Low	Upgrade at convenience

3. Fix availability — Is there a patched version? If not, what's the workaround?

Phase 5: Detect Bloat

1. Unused dependencies — Dependencies imported nowhere in the codebase.
2. Duplicate functionality — Multiple packages doing the same thing (2 HTTP clients, 2 JSON parsers).
3. Heavy transitive trees — Packages that pull in dozens of sub-dependencies for a simple feature.
4. Size analysis — Large packages used for small functionality.

Phase 6: Report

Output Format

## Dependency Audit: {Project Name}

### Summary
| Metric | Count |
|--------|-------|
| Direct dependencies | {N} |
| Transitive dependencies | {N} |
| License issues | {N} |
| Maintenance concerns | {N} |
| Security vulnerabilities | {N} |
| Bloat candidates | {N} |

### License Compliance

| Package | Version | License | Compatible | Issue |
|---------|---------|---------|------------|-------|
| {pkg} | {ver} | MIT | Yes | None |
| {pkg} | {ver} | GPL-3.0 | No | Copyleft in proprietary project |
| {pkg} | {ver} | Unknown | Unknown | License not identifiable |

### Maintenance Health

| Package | Last Release | Commits (90d) | Maintainers | Status |
|---------|-------------|---------------|-------------|--------|
| {pkg} | {date} | {N} | {N} | {Healthy/Warning/Abandoned} |

### Security Vulnerabilities

| Package | Version | CVE | Severity | Fix Available | Fixed In |
|---------|---------|-----|----------|---------------|----------|
| {pkg} | {ver} | {CVE-ID} | {severity} | {Yes/No} | {version} |

### Bloat Analysis

| Package | Install Size | Used By | Recommendation |
|---------|-------------|---------|----------------|
| {pkg} | {size} | {usage description} | {Remove/Replace/Keep} |

### Action Items

#### Immediate (Security)
1. Upgrade {pkg} to {version} — fixes {CVE-ID} ({severity})

#### Short-term (License)
1. Review {pkg} GPL usage — may require license change or removal

#### Medium-term (Maintenance)
1. Find alternative to {pkg} — abandoned since {date}

#### Long-term (Bloat)
1. Remove {pkg} — unused in codebase
2. Replace {pkg} with lighter alternative

### Transitive Risk
- {direct-dep} depends on {transitive-dep} which has {issue}

Calibration Rules

1. Production dependencies first. Dev/test dependencies have lower risk since they don't ship to users. Audit production dependencies with higher scrutiny.
2. Transitive risk is real. A direct dependency with MIT license may pull in a GPL transitive dependency. Always check the full tree.
3. Abandoned is not broken. A mature, stable library that hasn't been updated in a year may be perfectly fine. Evaluate based on whether the library is "done" vs "neglected."
4. Security is non-negotiable. Critical and High CVEs must be addressed immediately. Medium CVEs should be tracked. Low CVEs can wait for the next dependency update cycle.

Error Handling

When NOT to Audit

• The project is a prototype that won't ship — defer audit until production decision
• The user wants dependency updates, not audit — different task (dependabot, renovate)
• The project has no dependencies (pure standard library) — nothing to audit