Dependency Audit

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 deserialization in sessions (use JSON serializer)
• Secret key committed to source control

Rails:

• Mass assignment without strong parameters
• SQL injection via where("column = '#{input}'")
• Unpatched Action Pack, Action View, or Active Record CVEs
• Insecure deserialization in cookies (verify secret_key_base rotation)
• CSRF token bypass in API-only mode

Express / Node.js:

• Prototype pollution through Object.assign, lodash.merge, deep-extend
• ReDoS (Regular Expression Denial of Service) in validation patterns
• Path traversal through req.params in file serving routes
• Missing rate limiting on auth endpoints
• eval() or Function() with user input
• Event loop blocking with synchronous operations

Serverless / edge runtimes (Vercel, Lambda, Cloud Run, Workers):

• In-memory state ≠ rate limit. A module-scoped Map or Set for rate limiting, sessions, or caches is per-instance. Cold starts reset state; load spreads across instances; attackers bypass trivially.
  • Grep for: const rateLimitMap = new Map, const cache = new Map in server-action / API-route files
  • Fix: shared store — Vercel KV, Upstash Ratelimit, Redis, DynamoDB
• Unbounded in-memory collections leak memory under traffic. Cap size and evict (LRU or FIFO).
• x-forwarded-for trust: only trustworthy when the edge overwrites it. Behind misconfigured proxy chains it's attacker-spoofable. A fallback to a single "unknown" bucket throttles all anonymous traffic together; random-fallback silently disables the limit.

Spring / Java:

• Spring4Shell and related RCE vulnerabilities
• Deserialization attacks (Java native serialization, Jackson polymorphic types)
• SpEL injection in Spring Expression Language
• Missing CSRF protection on state-changing endpoints
• Actuator endpoints exposed without authentication

Laravel / PHP:

• APP_DEBUG=true in production (leaks env vars in error pages)
• SQL injection via raw DB queries without bindings
• Mass assignment without $fillable / $guarded
• File upload without type validation (PHP execution via uploaded .php)
• Insecure deserialization in queued jobs

WordPress:

• Outdated core, theme, or plugin versions (most common attack vector)
• File editor enabled in wp-admin (allows code injection if admin is compromised)
• XML-RPC enabled (brute force amplification, SSRF)
• Default admin username, weak passwords
• Unpatched plugin vulnerabilities (check WPScan database)