PRE-RELEASE DEPENDENCY AUDIT — multi-language, prioritized for a
next-week ship. Shape below; run against your lockfiles for actuals.

BLOCKING THIS RELEASE
  ▸ CVE in a transitive dep (not something you installed directly)
    lodash <4.17.21 pulled in via a build tool. Prototype pollution,
    high severity. The trap: it's not in your package.json, so a
    surface "npm audit" glance can miss why it's there. Fix: force the
    resolution or bump the parent.
  ▸ GPL-licensed package in a proprietary build
    One transitive dependency is GPL. If you ship binaries, that's
    contamination — legal-blocking, not just a warning. Replace or
    isolate before release.

FIX THIS RELEASE IF YOU CAN
  ▸ 3 direct deps behind by a minor with published CVEs, all
    patch-safe (no breaking changes). Low-risk bumps.

DO NOT TOUCH BEFORE THE RELEASE
  ▸ React 18 → 19 major. It's tempting, it's out of scope, and a major
    bump the week of a release is how a security audit becomes an
    outage. File it as a post-release upgrade with its own plan.

SAFE-UPGRADE PATHS (the part a plain audit doesn't give you)
  For each flagged package: current → safe target, and whether the jump
  is patch (safe now), minor (safe, test), or major (defer). This is
  what turns "you have 14 vulnerabilities" into "fix these 4 now, defer
  1, ignore 9 dev-only."

DEV-ONLY, DEFERRABLE
  9 of the findings are in devDependencies and never ship. Real, but
  they don't gate a release — separated so they don't inflate the
  urgent count.

RELEASE CALL
Block on the two above (CVE + GPL). The three minor bumps are your call
— safe, but a diff is a diff the week of a ship. Point me at the
lockfiles and I'll produce the real prioritized list.