Why is severity alone often not enough to rank open source vulnerability findings?

Why severity is only the starting point

Severity is a useful signal, but it is not a prioritisation model by itself. In open source estates, one package can pull in many transitive dependencies, so a high score may describe a flaw that is present in a library path your application never executes, or in code that sits outside the business-critical flow. Practitioners need to separate vulnerability severity from actual exposure, reachable attack surface, and business impact.

That distinction matters because “more severe” does not always mean “more urgent.” A medium-severity issue in a hot path, internet-facing component, or privileged build pipeline can be more important than a high-severity flaw in dead code or a test-only dependency. The question is not whether the finding is serious in the abstract, but whether it is exploitable in your environment and whether it can affect something you care about.

When organisations rely on package-level scores alone, they often end up with long queues, duplicated findings, and little ability to tell which issues threaten production systems. The better prioritisation unit is the combination of severity, exploitability, and dependency context, especially whether the vulnerable component is actually loaded, invoked, or able to influence a critical asset.

What context changes the ranking

Context changes ranking because it answers the questions that severity cannot: Is the vulnerable function reachable? Is there an attacker-controlled input path? Is the affected dependency shipped to production? Does the package sit in a trusted control plane, build pipeline, or authentication path? Those details often decide whether a finding is actionable now or simply a tracking item.

Open source vulnerability triage also needs to account for dependency depth and packaging structure. A flaw in a direct dependency that is exposed to user traffic is usually more relevant than an identical flaw buried several layers down, especially when compensating controls or unused code paths limit practical risk. Likewise, a dependency with broad reuse across applications may deserve elevated attention if one fix removes exposure across many assets.

For open source supply chain, severity is best treated as a filter, not a verdict. Tools such as the NIST National Vulnerability Database and FIRST CVSS help standardise the baseline score, but teams still need their own reachability, exposure, and asset criticality analysis before they can rank findings credibly. For open source estates, the OpenSSF ecosystem is also useful for shifting from score-only thinking toward supply chain hygiene and maintainability.

Risk and Threat Considerations

Severity-only triage creates two common failure modes: teams either waste time on issues that cannot be reached, or they miss lower-scored vulnerabilities sitting in internet-facing or high-trust code paths. Attackers benefit from that gap because they care about reachability, privilege, and impact, not the abstract score attached to a CVE.

Failure mechanism: A high-score finding in unused code can consume remediation capacity while a genuinely reachable flaw remains open because the package score looked less urgent on paper, or because the dependency was assumed to be “just a library.”

Impact: The result is misallocated effort, delayed remediation of exploitable issues, and a weaker view of which findings can actually be used for code execution, data exposure, or lateral movement in production.

Practitioner Guidance

What to verify: Confirm whether the vulnerable code path is reachable in the deployed build, whether the package is direct or transitive, and whether the affected function sits on a critical request, authentication, or build path. If you cannot answer those questions, do not let the severity score decide the queue order on its own.

What to measure: Track exploitability, reachability, affected asset criticality, and time-to-remediate by exposure class rather than by score alone. That gives you a ranking model that reflects operational reality instead of only vulnerability metadata.

Practitioner takeaway: Severity tells you how bad a flaw could be in the abstract, but context tells you whether it is actually a priority in your environment.

Related resources from NHI Mgmt Group

• Why do severity scores alone fail to capture real risk for vulnerable open-source components?
• Why does vulnerability severity alone often lead to poor remediation decisions?
• Why do open source vulnerability scanners often create more noise than decision value in DevSecOps pipelines?
• Why do vulnerability findings often remain open for weeks after discovery?