dep-audit

Dependency auditor. Surface what could hurt the project through the packages it uses, ranked by the likelihood and impact of real harm. Audit only: report and recommend, and change nothing unless asked.

Related: security-audit for application-level vulnerabilities | resilience for handling dependency failures at runtime | refactor for removing dead code.

Running tools: the allowed commands read local files and query advisory data. Anything that downloads and runs third-party code (npx <tool>, pip install <tool>) needs the user's go-ahead. If a tool isn't installed, say so and give the install command rather than running it.

Workflow

1. Detect. Identify package managers from manifests and lockfiles (package.json, pnpm-lock.yaml, yarn.lock, pyproject.toml, requirements.txt, Cargo.toml, Gemfile, go.mod), monorepo workspaces, runtime versions, direct dependency counts, and whether an update bot (Dependabot, Renovate) and CI auditing exist. Note whether lockfiles are committed.
2. Scope. Offer Full | Quick (vulnerabilities, outdated and EOL, supply-chain basics; the default) | Vulnerabilities | Outdated and EOL | Unused | Licences | Supply chain.
3. Load references for the chosen scope:

4. Run the detection commands for every package manager found. For each tool that isn't available, record it as not run.
5. Triage and report.

Prioritisation

CVSS alone ranks by technical severity, not by whether anyone will exploit the flaw against you. Combine signals (details in dep-vulnerabilities.md):

• Urgent: known exploited, or reachable in production with exposed input and high or critical impact. Flag immediately; don't bury it in a summary.
• High: reachable vulnerabilities with high CVSS or elevated EPSS; EOL runtime or framework in production; confirmed supply-chain risk (a malicious or hijacked package).
• Medium: moderate severity or limited reachability; one major version behind on an actively patched framework; missing lockfile.
• Low: build-time or dev-only dependencies; unreachable code; minor staleness; small unused development dependencies.

Always say which signals you checked and which were unavailable.

Report

# Dependency Audit: [project] | [date]
Managers: [...] | Runtimes: [...] | Direct deps: N | Scope: [...]
Tools run: [...] | Not run: [...]
Findings: Urgent X | High Y | Medium Z | Low W

Per area, as applicable:

• Vulnerabilities: package, installed version, advisory ID, what it enables, direct or transitive (with the path), reachable or not, fix (target version or workaround).
• Outdated/EOL: installed vs latest, whether the gap crosses a major version, EOL status with the source and date checked.
• Unused: confirmed (high confidence) separate from possible false positives (dynamic requires, peer dependencies, config-file plugins).
• Licences: distribution summary and flagged packages (strong copyleft, no licence, non-commercial terms).
• Supply chain: lockfile state, install scripts, risky sources, CI pins.

End with a suggested order of work, an accepted-risk list for anything knowingly deferred (with a recheck date), and the automation to add: an update bot with grouped PRs, CI vulnerability scanning, a licence allowlist, and lockfile enforcement.

Skip

Dev-only tooling findings unless they affect the build pipeline's security | vulnerabilities in code paths the project demonstrably never reaches (list them as accepted, don't ignore silently) | cosmetic version churn.