Ask whether the vulnerable code ships before you treat it as urgent
Filtering vulnerability findings by whether the dependency actually ships, and by whether a version bump resolves it, separates the small urgent set from the large noisy one — 81% were fixable by a simple version bump and only 1% sat on an unmaintained library needing a real mitigation.
Do this firstA bot proposes the dependency update; a human still has to land it
Presence in the tree is not exposure. Before an alert takes anyone’s afternoon, establish that the code ships, and that a bump does not just fix it.
The distribution is what makes triage worth building rather than reacting to each finding in turn. Most of the list is either not deployed or trivially fixable; the part that needs judgement is around one in a hundred. A process that treats all findings alike spends its attention uniformly on a set whose importance is anything but.
The honest limit, which the study states about itself: deployed scope is still a static proxy. It rules out the dependency that was never shipped; it does not prove the vulnerable function is ever called.
The decoy
The scanner’s finding count. Matching advisory identifiers against a dependency tree overstates exposure: about 20% of dependencies flagged as vulnerable in one measured portfolio were test- or build-scoped and never deployed at all, so they could not be exploited in practice.
Evidence
- Vulnerable Open Source Dependencies: Counting Those That Matter — IIISeparates presence from exposure: about 20% of dependencies flagged as affected by a known vulnerability are never deployed — test or build scope only — and cannot be exploited in practice. Of the deployed ones, 81% are remediable by a simple version bump, the library's own developers can fix 82% directly, and only 1% sit on an unmaintained library with no fix available.
Last reviewed 2026-08-19.