Why do severity scores alone fail to capture real risk for vulnerable open-source components?

Severity scores are useful starting points, but they do not account for how a library is used inside a specific application. A component may be present but dormant, confined to test code, or shielded by limited exposure. Real prioritisation requires code, runtime, deployment, and business context to estimate likelihood and impact accurately.

Why This Matters for Security Teams

Severity scores are a coarse signal, not a risk decision. A high CVSS score can describe technical exploitability, but it does not tell a team whether the vulnerable component is reachable, whether it is used in production, or whether compensating controls already block abuse. That gap is why Top 10 NHI Issues and adjacent software supply chain reviews increasingly focus on exposure, privilege, and runtime context instead of score alone. NIST also frames cybersecurity outcomes around asset context, protection, and response rather than raw severity in the NIST Cybersecurity Framework 2.0.

This matters because open-source components are often embedded deeply in builds, transitive dependencies, and test paths. A library may be present but unused, or only loaded in a low-impact workflow, while a lower-scored flaw in a public-facing service can create immediate operational exposure. In NHI and agentic environments, the same mistake is amplified when libraries handle secrets, tokens, or tool execution paths. The 2024 ESG Report: Managing Non-Human Identities notes that 72% of organisations have experienced or suspect a non-human identity breach, underscoring how quickly “theory” becomes incident response once identity-bearing components are involved. In practice, many security teams discover true exposure only after an exploit path has already been chained through a dependency they had marked low priority.

How It Works in Practice

Effective prioritisation starts by combining vulnerability data with application and deployment context. Security teams should ask four questions before acting on a finding: Is the component reachable? Is the vulnerable code path actually invoked? What privileges does the process or workload have? What would be the business impact if it were compromised?

That approach aligns with the risk-based logic in the NIST Cybersecurity Framework 2.0 and with the way NHIMG describes real-world compromise patterns in the 2024 ESG Report: Managing Non-Human Identities. A vulnerable package in a build-only dependency may deserve monitoring, while the same flaw in a service that processes production secrets may require immediate patching, isolation, or compensating controls.

• Map dependencies to the services, containers, and workloads that actually load them.
• Separate internet-facing, authenticated, internal, and offline use cases.
• Score exploitability using runtime reachability, privilege, and data sensitivity.
• Track whether secrets, tokens, or identity assertions pass through the component.
• Use compensating controls such as segmentation, allowlisting, and feature flags when patching is delayed.

For NHI-adjacent systems, this is especially important because a vulnerable library may expose service credentials, signing keys, or API tokens rather than only application data. Attackers often care less about the score and more about whether the component sits on a path to a valuable identity or control plane. These controls tend to break down in large monorepos and containerised microservices because ownership, transitive dependency chains, and runtime reachability are difficult to reconstruct quickly.

Common Variations and Edge Cases

Tighter scoring discipline often increases triage overhead, requiring organisations to balance speed against accuracy. That tradeoff is real: not every team can fully instrument runtime reachability or business impact for every package on day one, and current guidance suggests starting with the highest-exposure assets first. In mature environments, the best practice is evolving toward risk-based exception handling instead of universal patch deadlines.

One common edge case is a critical vulnerability in a test-only or build-only dependency. The score may look severe, but the real risk remains low unless the package is promoted into production or can influence build artefacts. Another is a medium-severity flaw in a component that handles secrets, signs tokens, or runs with elevated privileges. Here, the lower score can still mask high practical risk. NHIMG’s guidance on the Ultimate Guide to NHIs — Key Challenges and Risks reflects the same principle: identity context changes the meaning of exposure. The OWASP NHI Top 10 also reinforces that vulnerable components become far more urgent when they sit on paths to credentials, tool access, or automated execution.

There is no universal standard for this yet, but the practical direction is clear: treat severity as an input, then override it with runtime, privilege, and business context before deciding what to fix first.

Related resources from NHI Mgmt Group

• When does a compliance score fail to capture real governance risk?
• Why do risk scores often fail to reflect real identity exposure?
• Why do high CVSS scores often fail to reflect real business risk?
• Why do vulnerability scores often fail to reflect real risk in financial environments?