/dependency-audit

name: dependency-audit
description: "Audit project dependencies, frameworks, languages, and dev tools for known vulnerabilities, CVEs, and security anti-patterns. Use when the user mentions 'dependency audit,' 'npm audit,' 'CVE,' 'vulnerable packages,' 'supply chain security,' 'outdated dependencies,' 'known vulnerabilities,' 'security advisory,' 'package security,' 'framework vulnerability,' 'is this package safe,' or needs to check whether their stack has known security issues."
allowed-tools: Bash, Read, Write, Grep, Glob, WebSearch

Dependency Audit — Framework, Package, and Toolchain Security

Audit project dependencies, frameworks, language runtimes, and dev tools for known vulnerabilities (CVEs), security anti-patterns, and supply chain risks.

Methodology

Step 1: Inventory the Stack

Identify everything in use — not just direct dependencies but the full chain:

**Package manifests — read and catalog:**

Node/JS:    package.json, package-lock.json, yarn.lock, pnpm-lock.yaml
Python:     requirements.txt, Pipfile.lock, pyproject.toml, poetry.lock
Ruby:       Gemfile, Gemfile.lock
Go:         go.mod, go.sum
Rust:       Cargo.toml, Cargo.lock
Java:       pom.xml, build.gradle
PHP:        composer.json, composer.lock
.NET:       *.csproj, packages.config

**Framework and runtime versions:**

• Check framework version (Next.js, Django, Rails, Spring, Laravel, Express, etc.)
• Check language/runtime version (Node.js, Python, Ruby, Go, Java, PHP, .NET)
• Check infrastructure tools (Docker base images, Terraform providers, Kubernetes versions)

**Dev tools and CI/CD:**

• Check CI/CD pipeline configs (.github/workflows, .gitlab-ci.yml, Jenkinsfile)
• Check pre-commit hooks, linters, formatters
• Check container base images and their update status
• Check IaC tool versions (Terraform, Pulumi, CDK)

**Edge cases in package manifests:**

• `optionalDependencies` — installed but not audited by default
• `peerDependencies` — version range may not match what's installed
• `overrides` / yarn `resolutions` / pnpm `overrides` — check if used to *silence* advisories rather than fix them
• Monorepos: read every `packages/*/package.json` and `apps/*/package.json`, not just the root
• `engines` field — older-than-LTS Node makes other audits moot

Step 2: Run Automated Audit Tools

Run the appropriate audit command for the project:

# Node.js
npm audit --json                # full structured output
npm audit --omit=dev --json     # production-only: filters dev/build-time vulns
# Compare the two — vulns only in dev/build tooling do not ship to users
# and should be triaged as lower priority. Don't bury this in the report.

# Python
pip audit          # If pip-audit installed
safety check       # If safety installed

# Ruby
bundle audit

# Go
govulncheck ./...

# Rust
cargo audit

# PHP
composer audit

# .NET
dotnet list package --vulnerable

# Docker
docker scout cves <image>
trivy image <image>

# General (if Trivy is available)
trivy fs .

**Applying fixes — read before you `--force`:**

npm audit fix                   # safe: upgrades within stated ranges
npm audit fix --dry-run --force # ALWAYS dry-run first
npm audit fix --force           # only after reviewing the dry-run

`npm audit fix --force` can resolve an advisory by DOWNGRADING a package to an older version that doesn't trigger the audit signature. This is almost always wrong (e.g. downgrading `next@16` to `next@9` to "fix" a transitive postcss CVE). Inspect dry-run output for "Will install X@Y, which is a breaking change" — that's the tool trying to downgrade.

**When `npm audit fix` cannot resolve an advisory** (transitive dep pinned by an upstream package):

1. **Determine reachability** — is the vulnerable code path actually invoked in your usage? `npm ls <package>` + reading the parent's source can rule it out as unreachable. 2. **Consider a `package.json` `overrides` pin** to a patched version (test thoroughly — overrides can break the parent). 3. **Consider swapping the parent provider entirely.** 4. **If none apply:** document explicitly, track upstream, and note in the audit report rather than silently dropping the finding.

Step 3: Research Framework-Specific Known Issues

Beyond CVEs in packages, check for known vulnerability patterns specific to the framework in use. Search for recent advisories and common misconfiguration issues.

For every direct dependency, cross-reference the installed version against:

• `https://github.com/advisories?ecosystem=npm&query=<package>`
• `https://github.com/<org>/<repo>/security/advisories`

The framework-specific patterns below cover *evergreen* anti-patterns (mass assignment, debug-in-prod, etc.). Recent CVEs need a fresh check because hardcoded advisory lists rot fast and LLM training data is often 6+ months behind the latest.

**Next.js / React:**

• Server Actions exposing internal endpoints (pre-14.1.1 middleware bypass CVE-2025-29927)
• `dangerouslySetInnerHTML` without sanitization
• SSRF through image optimization (`next/image` with unrestricted domains)
• Exposed `.env` files in public directory or client bundle (`NEXT_PUBLIC_` prefix leaking secrets)
• Middleware auth bypass patterns — check middleware.ts matches all protected routes
• Server Component / Client Component boundary leaking server-only data:
• Any module reading `process.env.SECRET` or instantiating a DB client should start with `import "server-only";` — fails the build if imported from a Client Component
• Grep for: files in `lib/` that touch `process.env.[A-Z_]+` but do NOT import `server-only`
• Inverse check: any file with `"use client"` importing from such a module is a leak
• Outdated `next.config.js` security headers

**Django:**

• DEBUG=True in production
• ALLOWED_HOSTS misconfigured (wildcard `*`)
• Missing CSRF middleware or `@csrf_exempt` on state-changing views
• Raw SQL via `extra()`, `raw()`, or `RawSQL` without parameterization
• Pickle deserializa