Dependency vulnerability remediation

Security Advisory Remediation

When to Use

Use when responding to npm audit, pnpm audit, yarn npm audit, composer audit, pip-audit, cargo audit, Dependabot, Snyk, Trivy, or GitHub Security Advisories (GHSA / CVE).

Golden Rule: Never Run Blind audit fix --force

Running npm audit fix --force frequently downgrades or upgrades major versions of top-level frameworks to incompatible versions, breaking the application while sometimes leaving the vulnerable code path unresolved. Every security remediation must be triaged for reachability and applied surgically.

Vulnerability Triage & Reachability Analysis

1. Verify Advisory Details & Affected Version Range

• Read the actual CVE / GHSA advisory:
  • What is the vulnerability class? (RCE, prototype pollution, ReDoS, SSRF, path traversal, SQLi, XSS, cryptographic weakness, DoS).
  • Which exact versions are affected, and which minimum patched version (patched_versions) resolves it on the current major release branch?

2. Assess Code-Path Reachability & Environment Exposure

Before proposing a disruptive major upgrade, determine whether the vulnerable function or condition is reachable:

1. Execution Context: Is the package in dependencies (production runtime) or strictly in devDependencies (local linter, test runner, docs generator that never processes untrusted input or runs in production)?
2. Call-Site Reachability: Trace npm explain <pkg> / pnpm why <pkg> / composer why <vendor/pkg> / cargo tree -i <crate>:
   • Which parent package imports the vulnerable dependency?
   • Does the parent package invoke the vulnerable API or pass user-controlled input to it?
3. Mitigating Controls: Is the vulnerable input already bounded (e.g., a ReDoS regex only ever runs on build-time static config files, not user HTTP input)?

Always state clearly whether a finding is Exploitable in Production, Reachable Only in Build/CI, or Unreachable Transitive Noise, so risk prioritization is factual.

Surgical Remediation Strategies (Least Disruptive First)

Strategy 1: Lockfile-Only Transitive Refresh (Semver-Compatible)

If the parent dependency's declared range (^1.2.0) already permits the patched version (1.2.5), refresh only that transitive entry in the lockfile:

• npm update <vulnerable-pkg> --depth 5
• pnpm up <vulnerable-pkg> -r
• composer update <vendor/vulnerable-pkg> --with-dependencies
• uv lock --upgrade-package <vulnerable-pkg>
• cargo update -p <vulnerable-pkg> --precise <patched-version>

Strategy 2: Direct Parent Minor/Patch Upgrade

If the direct dependency pins an older range of the transitive package, check if a minor or patch release of the direct parent updates the transitive constraint.

Strategy 3: Scoped Override / Resolution Pin

When the upstream parent has not yet released an update, pin the transitive dependency to the patched version using a scoped override:

• Scope the override to the specific parent ("overrides": { "parent-pkg": { "vuln-pkg": "^1.2.5" } }) rather than forcing it globally if other packages need a different major.
• Verify that the parent package's tests and runtime calls work with the overridden version (especially if the patched version is a new major!).
• Document the CVE ID, why the override exists, and when it can be removed.

Strategy 4: Package Replacement or Input Mitigation

If the package is abandoned (unmaintained, no patched version exists):

1. Check whether an official fork or drop-in replacement exists from a trusted maintainer.
2. If replacing or upgrading is blocked, implement input validation/sanitization at the call boundary to neutralize the exploit vector and document the residual advisory exception.