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:

Step 2: Version Currency Assessment

For each dependency, evaluate how current it is:

Currency classification:

Generate a currency report table:

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):

Generate a vulnerability report table:

Step 4: License Compliance

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

License risk classification:

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:

Step 5: Unused and Redundant Dependencies

Identify dependencies that can be removed:

Detection methods:

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:

Size concern thresholds (frontend/browser context):

Generate a size impact table (for top offenders):

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.