No known critical CVEs in production dependencies

OWASP A06 (Vulnerable and Outdated Components) is the category behind some of the most damaging breaches in recent memory. A single critical CVE in a production dependency — like prototype pollution in lodash or remote code execution in a widely-used serializer — gives an attacker a direct entry point into your running application. The CISA KEV catalog tracks CVEs with confirmed exploits in the wild; if any of your dependencies appear there, your production environment is actively targeted. SSDF PW.4 requires that software be tested for weaknesses, and shipping with known critical vulnerabilities is a categorical failure of that control. CWE-1357 (Reliance on Insufficiently Trustworthy Component) names the exact defect class. A critical CVE is not a theoretical risk — it is a scored, published attack path with a working exploit.

Run npm audit fix immediately. For vulnerabilities that cannot be auto-resolved, pin the fixed version or use overrides in package.json as a bridge:

"overrides": {
  "vulnerable-transitive-dep": "^2.0.0"
}

After patching, verify no critical issues remain with npm audit --omit=dev --audit-level=critical. Add this command to your CI pipeline so critical CVEs block merges before they reach production.

• ID: no-critical-cves

• Severity: critical

• What to look for: Examine package.json dependencies for packages with known critical CVEs. The most reliable method is inspecting whether the project has an npm audit (or equivalent) step in CI or scripts. If you can execute npm audit --json --audit-level=critical (or pnpm audit / yarn audit), do so and review the output. If you cannot run commands, look at the lock file for known-vulnerable version pinning of high-profile packages: check the resolved versions of packages like lodash (<4.17.21), minimist (<1.2.6), semver (<7.5.2), word-wrap (<1.2.4), json5 (<1.0.2 or <2.2.2), loader-utils (<2.0.4), ansi-regex (<5.0.1 or <6.0.1), nth-check (<2.0.1), postcss (<8.4.31), express (<4.19.2). Flag any match. Count every critical severity vulnerability reported by the audit tool. Enumerate each with its CVE ID, affected package, and severity.

• Pass criteria: No known critical CVEs found in production dependencies via npm audit output, or manual inspection of lock file versions finds no critical-severity matches against well-known CVE version ranges. Report even on pass: "X total dependencies scanned. 0 critical vulnerabilities found. Last audit date: Y." At least 1 implementation must be confirmed.

• Fail criteria: One or more production dependencies are on versions with known critical CVEs, per npm audit output or lock file version range inspection.

• Error when: package.json cannot be located or read. Do NOT pass if any critical vulnerability has a known exploit in the wild (CISA KEV catalog) — even a single actively exploited vulnerability is a blocking finding.

• Skip (N/A) when: Project has no package.json and uses a non-npm ecosystem (Go modules, Cargo, etc.) where this check doesn't apply. Signal: no package.json, no lock file, and no node_modules.

• Cross-reference: The no-typosquatting check verifies that the dependencies scanned for vulnerabilities are legitimate packages, not malicious lookalikes.

• Detail on fail: Name the affected package(s) and their installed version. Example: "lodash@4.17.4 in dependencies has critical prototype pollution CVE (CVE-2020-8203). Run 'npm audit fix' to resolve." Never include more than 3 packages to stay under 500 chars.

• Remediation: Your project has production dependencies with known critical security vulnerabilities. Critical CVEs represent actively exploitable attack paths — these should be fixed before deployment.

  Run the audit and auto-fix where possible:

  npm audit fix
  

  For vulnerabilities that cannot be auto-fixed (often due to breaking changes), review the advisory and manually upgrade:

  npm install package-name@latest
  

  If a transitive dependency (not one you installed directly) is vulnerable, check if updating the direct parent package resolves it. If not, use overrides in package.json as a temporary measure:

  // package.json
  "overrides": {
    "vulnerable-transitive-dep": "^2.0.0"
  }
  

  After fixing, re-run npm audit --omit=dev --audit-level=critical to verify no critical issues remain.

  For a comprehensive review of transport and header-level security protections that complement dependency security, the Security Headers & Basics Audit covers that in detail.