Patch with context

A known vulnerable component is not automatically exploitable in your product. It is still a signal you must investigate, and “investigate” has concrete steps.

Dependency scanners hand you a steady stream of advisories. Panic-patching everything wastes the week; ignoring everything loses the one advisory that matters. Context is how you tell them apart.

Four questions per advisory

• The affected version: is the vulnerable range what you actually run?
• The reachable feature: does your code call the vulnerable path?
• The privilege required: anonymous visitor, or authenticated admin?
• The possible impact: code execution and data exposure outrank a crash.

Start with what is installed:

npm audit
npm ls sharp   # who pulls this in, and which version resolves

npm ls matters because lockfiles resolve transitive versions you never chose. The advisory applies to what is installed, not to what your package.json mentions.

Reachability is the honest test

An advisory affects image parsing, and the application processes user uploads through that exact function. That is reachable: anonymous users feed bytes directly into the vulnerable code. Patch it now.

The tempting dodge is “the package is indirect.” Indirect does not make the path unreachable — your direct dependency calls it for you, with your users’ input. Trace the call path from your route handler down to the vulnerable function and save that evidence. It justifies the urgency today and explains the decision next quarter.

Then apply the smallest supported fix and test the important path:

npm install [email protected]   # the patched release, not a new major
npm test

A rushed major upgrade can break production, and a security patch that causes an outage teaches the team to fear patching. Patch releases exist so the fix and the redesign travel separately. If a safe reproducer for the malformed input exists, run it against the fixed version too.

When you genuinely cannot patch yet

Sometimes the fixed version needs a migration you cannot ship today. Deferring is legitimate. Silent deferring is not. Record the reason, a compensating control, an owner, and a deadline:

advisory: GHSA-xxxx (image parser overflow)
deferred: fix requires Node 22, migration ticket INFRA-412
mitigation: uploads disabled for unverified accounts
owner: platform team    review by: 2026-09-01

A dated mitigation with a name on it gets revisited. An unwritten one becomes permanent.