Dependency Audit Checklist

What this template is

Your application is mostly other people’s code. In a typical Node.js or Python project, the code your team wrote is a thin layer on top of hundreds of transitive dependencies, and each one is a potential vulnerability, an abandoned project, or a license problem. This checklist is a repeatable procedure for auditing that layer.

It is written for the engineer who owns “check our dependencies” as a quarterly task, and for teams preparing for a security questionnaire or due diligence. Copy the markdown into your tracker and run it per repository. The first pass takes half a day; subsequent passes take an hour or two because the automation you set up in section 6 does the watching between runs. For the reasoning behind each step, see auditing third-party dependencies; for exact commands per ecosystem, the dependency audit tutorial is the companion piece.

1. Inventory: know what you actually run

• Generate the full dependency tree, including transitive packages: npm ls --all, pipdeptree, mvn dependency:tree, or the ecosystem equivalent
• Count direct vs transitive dependencies and record the numbers; the trend across audits matters
• Remove unused dependencies: run depcheck (JS) or pip-extra-reqs and delete what nothing imports
• Identify duplicate packages solving the same problem (two date libraries, two HTTP clients) and pick one
• Confirm production and development dependencies are correctly separated, and dev tools do not ship in the production image

2. Known vulnerabilities

• Run the ecosystem scanner: npm audit --omit=dev, pip-audit, bundler-audit, cargo audit, or govulncheck
• Cross-check with an independent scanner (osv-scanner or Trivy) since advisory databases differ
• For every critical and high finding, determine reachability: is the vulnerable function actually called from your code?
• Fix, upgrade, or document: every critical/high either gets patched or gets a written exception with a reason and a review date
• Check container base images too if you ship Docker: trivy image <your-image>

3. Maintenance health

• For each direct dependency, check the last release date; flag anything silent for over 18 months
• Check open issue and PR responsiveness on your top 10 most critical packages; an unmerged security PR is a red flag
• Identify single-maintainer packages in your critical path and note them as concentration risk
• Flag deprecated packages (npm marks these on install) and plan replacements
• Check that pinned major versions are still receiving security patches; being two majors behind often means no patches at all

4. Licenses

• Generate a license inventory: license-checker (JS), pip-licenses, or your SCA tool’s report
• Confirm nothing copyleft (GPL, AGPL) sits in a product you distribute or sell access to, unless legal has signed off
• Flag packages with no license at all; no license means you technically have no right to use it
• Record the inventory somewhere due diligence can find it later

5. Lockfile and install hygiene

• A lockfile exists, is committed, and is not in .gitignore
• CI and production install from the lockfile exactly: npm ci, pip install -r with hashes, bundle install --frozen
• Lockfile changes show up in PR diffs and reviewers actually look at them
• Install scripts from new packages are reviewed; consider --ignore-scripts as a default where your stack allows it
• Internal package names are registered publicly or scoped, so dependency confusion attacks cannot substitute a public package for your private one

6. Automation: make the next audit cheap

• Dependabot or Renovate is enabled and configured to group minor updates
• The vulnerability scanner from section 2 runs in CI and fails the build on new critical findings
• Update PRs get merged on a cadence (weekly is realistic); an ignored bot is worse than no bot because it hides the signal
• A calendar entry exists for the next full manual pass, one quarter out

How to act on the results

Prioritize by reachability and exposure, not by CVSS score alone. A critical CVE in a function you never call is lower urgency than a high CVE in your request-parsing path. Patch reachable criticals within days. Batch routine upgrades into a regular slot instead of letting them queue, because upgrade pain grows nonlinearly with delay: two majors behind is often a rewrite, one minor behind is usually a lunch break. The framework in how to prioritize fixes after an audit applies directly.

The single highest-leverage outcome of a first dependency audit is section 6. Findings decay in weeks; automation keeps paying.

Want us to run it for you (free)

Scanners list CVEs; they do not tell you which ones are reachable in your code, which abandoned package is quietly load-bearing, or which upgrade will break you. Submit your repository and a Webisoft engineer will audit your dependencies (and the rest of the codebase) manually, then send you a prioritized report, free: get a free code audit.