A Vulnerable Dependency Was Found. Does It Actually Matter?

Your scanner flagged forty vulnerable dependencies. Some fraction of those are genuinely dangerous in your application; most are not, and the difference is not visible in the advisory. Working through them in severity order — the default — spends your attention in roughly the wrong sequence. Five questions fix that.

A CVE describes a flaw in a function, not in a package. If your code never reaches that function, the flaw is present and not exploitable. The classic case is a library whose vulnerability is in a parser you never call, or in a CLI entry point when you import it as a module. This is the single largest source of legitimate deprioritisation — and the one most tools cannot answer for you, so it usually needs a developer who knows the codebase to look for five minutes.

A direct dependency you can upgrade in an afternoon is a different problem from one buried four levels down inside a framework that pins it. For transitive findings, check whether the parent has released a version that moves the pin — and if it has not, whether your package manager's override mechanism (overrides, resolutions, a constraints file) can force it without breaking the parent's assumptions.

Severity says how bad exploitation would be; it says nothing about whether exploitation is happening. EPSS gives you the probability, and CISA's KEV catalogue gives you confirmed activity. A medium-severity CVE on the KEV list outranks a critical nobody has ever weaponised — and the reverse mistake, patching alphabetically by severity, is how the actually-exploited one waits three weeks.

The same vulnerable package matters differently in an internet-facing service that handles untrusted input than in a build-time tool that runs on your CI runner. Not because the build tool is safe — a compromised build is a supply-chain event — but because the attack requires a different, harder starting position. Rank by what an attacker would have to already have.

If no patched version has shipped, the decision is not when to upgrade — it is whether to mitigate around it, replace the dependency, or accept and monitor. Writing that decision down, with a date to revisit, is the difference between a considered risk and a forgotten one.

The recurring trap is treating the flagged list as a queue rather than an inventory. It is an inventory; the queue is what these questions produce from it.

A Webcuris repository scan computes risk from severity, exploit probability and exposure together rather than severity alone — and runs locally, so your source never leaves the machine. What it hands you is closer to the queue than the inventory, with the evidence behind each ranking visible so you can disagree with it.