Making Dependency Vulnerability Alerts Worth Acting On

Most of that count comes from transitive dependencies, packages your direct dependencies pull in that you never chose and rarely interact with directly, plus advisories for code paths your application never actually executes. A scanner working from a manifest file alone can't tell the difference between a vulnerable function you call in your authentication flow and the same vulnerable function sitting unused in a dependency you only use for one unrelated utility.

That's not a reason to ignore the count, but it is a reason not to treat every line item as equally urgent. The first useful step isn't patching, it's separating the list into what's actually reachable from your code versus what's present but never called.

Prioritize by three factors together, not any one alone: whether the vulnerable code path is reachable from your application, whether the vulnerability is a known exploited one actively being used in the wild rather than theoretical, and whether the affected service is internet-facing. A theoretical, unreachable vulnerability in an internal batch tool can wait for the next scheduled dependency update. A known exploited vulnerability in a package your internet-facing API actually calls needs to move this week¹.

Resist patching in strict severity-score order without checking reachability first. A tool's severity score describes the vulnerability in isolation, not whether your specific usage of the dependency can trigger it, and treating the score as the only input wastes effort on issues that pose no real risk to your application.

A reachable vulnerability sits in a code path your application actually calls, directly or through a chain of function calls you can trace. An unreachable one exists in the dependency but in a function or configuration path your code never invokes, which doesn't mean it's safe to ignore forever, a future code change could make it reachable, but it does mean it's not an active risk today.

Some scanning tools can trace call graphs to determine reachability automatically; without that, a manual check of whether your code actually imports and calls the affected function is usually fast enough to do for anything flagged as high severity before deciding it's urgent.

Security can set the policy, what counts as urgent, what the patch timeline should be, but the team that owns the affected service should own the actual patch and the testing that confirms it didn't break anything. A central security team patching code it doesn't otherwise touch tends to move slowly and without full context on what else depends on the current version.

The most durable setup splits the work: security owns triage criteria, alert routing, and tracking whether patches actually land within the agreed timeline; the owning engineering team owns applying the patch, running tests, and shipping it. Endpoint and exposure management tools like CrowdStrike or Tenable can help security see which findings are actually being exploited against similar systems, which sharpens the triage call without taking the fix itself away from the team that owns the code.

A backlog that only grows means triage criteria are too loose or patch cadence is too slow. Fix the process, not just the current pile:

• Set a fixed cadence for routine dependency updates, weekly or biweekly, so most vulnerabilities get patched as a side effect of normal maintenance rather than requiring a special triage decision at all.
• Reserve the urgent, out-of-cycle patch path for the narrow case: reachable, known exploited, and internet-facing.
• Track time-to-patch for the urgent category specifically, separate from the routine backlog, since mixing the two metrics hides whether the truly urgent cases are actually moving fast.
• Review which dependencies generate the most repeated advisories over time; sometimes the real fix is replacing an unmaintained package rather than patching around it every month.

A team that patches on a steady cadence and reserves urgency for cases that are genuinely reachable and actively exploited ends up with a smaller, more trustworthy backlog than one that tries to triage every finding individually.