Vulnerability exploitability depends on reachability, not just CVSS score

At a glance

What this is: This is Seemplicity’s analysis of why CVSS and EPSS are insufficient on their own, and why reachability is the missing factor in vulnerability exploitability decisions.

Why it matters: It matters because IAM, PAM, and broader security teams need to prioritize real exposure, not theoretical severity, especially where access controls, segmentation, and runtime conditions change whether a flaw is exploitable.

By the numbers:

• Somewhere between 50 and 60% of all published CVEs land in "High" or "Critical".
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.

👉 Read Seemplicity's analysis of vulnerability exploitability and reachability

Context

Vulnerability exploitability is not the same as severity. A CVE can score 9.8 and still be irrelevant if the vulnerable code is not loaded, is never called, or sits behind controls that block any practical attack path. This article is about that gap, and it is especially relevant to IAM and NHI programmes because access controls, segmentation, and privilege boundaries often determine whether a flaw can actually be reached.

Security teams routinely over-prioritize scores because they are easy to compare, but scoring alone does not answer the operational question of whether the asset is reachable in the production path. In environments with service accounts, tokens, APIs, and layered controls, exploitability has to be proven against the live system, not inferred from a global metric.

Key questions

Q: How should security teams prioritise CVEs in production environments?

A: Prioritise CVEs by verified exposure, not just severity. A high-score vulnerability should move ahead only when the vulnerable component exists in production, is reachable from a realistic attack path, and lacks controls that block exploitation. That approach reduces noise, protects engineering time, and makes remediation decisions defensible.

Q: Why do CVSS scores often mislead NHI remediation decisions?

A: CVSS measures severity, not whether the vulnerable identity path is reachable or useful to an attacker. In NHI environments, reachability, privilege scope, and secret exposure often matter more than the raw vulnerability score, so teams can over-prioritise theoretical issues and under-prioritise active access risk.

Q: What breaks when vulnerability reachability is not checked?

A: Triage breaks first. Teams waste time on unreachable issues, SLA queues fill with noise, and confidence in remediation reporting drops because critical labels no longer reflect real attack paths. In identity-heavy environments, the same problem appears when access assumptions are made without validating the path.

Q: How do teams know if a vulnerability is truly exploitable?

A: They validate it in the live environment using safe testing that shows whether an attacker can reach the condition, trigger it, and move beyond it. Scanner data alone cannot answer that question reliably. Validation gives defenders evidence they can use to separate theoretical issues from immediate response priorities.

Technical breakdown

Why CVSS and EPSS do not measure reachability

CVSS is a severity rubric. It estimates how bad a vulnerability could be under defined conditions, while EPSS estimates the chance of exploitation in the wild based on external evidence. Neither model knows whether the vulnerable component is actually present in your production path, whether the function is loaded at runtime, or whether network and access controls block the attack path. That is why a critical score can describe a theoretical risk without proving exposure. The decision problem is local, not global, and it depends on deployment details that scoring systems do not see.

Practical implication: Use scores as inputs, not as escalation triggers, and require environment-specific reachability evidence before assigning remediation urgency.

What reachability analysis checks at runtime

Reachability analysis asks whether the vulnerable code is actually usable by an attacker in the current environment. For applications, that means checking whether the vulnerable function is invoked, imported, or loaded at runtime. For infrastructure, it means verifying whether the service is exposed, directly reachable, or shielded by controls such as segmentation, firewalls, or access restrictions. This is the difference between a flaw existing somewhere in a build and a flaw being exploitable on a live path. Runtime context is what converts a CVE from a label into a real incident candidate.

Practical implication: Map every high-severity finding to runtime exposure data before it enters an engineering queue.

How risk-based vulnerability management changes triage

Risk-based vulnerability management combines severity, likelihood, and exposure into one triage decision. A finding deserves priority when the vulnerable asset exists in production, is reachable, and lacks compensating controls. A high score without exposure should not consume the same SLA as a lower score with confirmed attackability. This model also requires evidence trails so that every non-exploitable verdict can be defended later, and continuous re-verification because deployment changes can turn an unreachable flaw into an exposed one overnight.

Practical implication: Build triage rules around exploitable exposure, not raw score thresholds, and attach evidence to every exception decision.

NHI Mgmt Group analysis

Reachability is the missing governance layer in vulnerability management. CVSS and EPSS are useful signals, but they are not a substitute for proving whether a flaw can be reached in the target environment. The deeper failure is a governance model that treats global risk scores as local truth. For IAM and NHI teams, the same mistake appears when access review and privilege assumptions are made without checking whether the path is actually open. Practitioners should treat reachability as a control requirement, not a nice-to-have analytic.

Score-led triage creates operational noise that hides real exposure. When most of the backlog is labelled critical, the label loses meaning and teams start burning effort on problems that never had an attack path. That is not just inefficient, it weakens confidence in remediation programmes and crowds out work on genuinely reachable assets. The security organisation needs a prioritisation model that separates theoretical severity from asset-specific exploitability.

Runtime exposure should become the decision point, not the CVE banner. The article is effectively describing a shift from vulnerability counting to exposure validation. That is a stronger model for NIST-CSF risk decisions, and it aligns with least-privilege thinking in identity programmes because access only matters when a path exists. Practitioners should optimise for verified exposure, not headline scores.

AI-driven investigation changes the economics of validation, but not the logic of control. Automating exploitability checks can make evidence-based triage scalable, yet the security decision still depends on runtime context, compensating controls, and change-aware revalidation. That means automation should be used to strengthen judgment, not replace it. The programme goal is faster proof, not blind trust in machine-generated priority.

What this signals

Reachability validation will increasingly become part of the vulnerability management operating model. Teams that can prove whether a finding is actually exposed will spend less time debating severity labels and more time fixing issues that matter. That shift will also improve board reporting because remediation queues will finally reflect real attack paths rather than generic risk scores.

Identity and access controls will be used more explicitly as exposure gates. In practice, segmentation, permissions, and runtime authorisation are not just guardrails, they determine whether an exploitable condition is reachable. The stronger the control boundary, the more likely a critical CVE becomes a theoretical issue rather than an incident candidate.

Evidence-led triage will matter more than volume-led scanning. As environments grow, the value is moving from finding more CVEs to proving which ones are reachable, exploitable, and change-sensitive. That is a better fit for modern programmes that need to align vulnerability response with identity, cloud, and application control ownership.

For practitioners

• Validate exploitability before escalation Require evidence that the vulnerable component is present in production, invoked at runtime, and not shielded by segmentation or access restrictions before opening a high-priority remediation ticket.
• Attach reachability evidence to every finding Record whether the function is loaded, the dependency is called, and any firewall, WAF, or security group control that blocks the path, so exceptions are auditable later.
• Re-tier SLAs by exposure state Give confirmed reachable flaws a tighter remediation clock than unreachable or theoretical issues, and revise those priorities whenever deployments or network controls change.
• Automate re-verification after change Re-check findings after releases, network changes, or control updates so an unreachable flaw does not become exploitable without detection.

Key takeaways

• CVSS and EPSS help describe a flaw, but they do not prove whether it can be reached in your environment.
• Reachability evidence turns vulnerability management from score chasing into defensible risk prioritisation.
• Security teams should treat runtime exposure, compensating controls, and re-verification as core parts of triage.

Key terms

• Reachability analysis: Reachability analysis checks whether a vulnerability can actually be exploited in the application’s real code paths and dependency graph. It helps teams distinguish theoretical findings from issues that an attacker can reach, which makes prioritisation far more accurate for both AppSec and identity risk management.
• Exploitability Management: Exploitability management is the practice of prioritising vulnerabilities based on whether they can actually be used in a specific environment. It combines vulnerability intelligence, asset reachability, and compensating controls so teams focus on exposure that can lead to real operational impact.
• Risk-based Vulnerability Prioritisation: A method of ordering remediation by how likely a flaw is to be exploited in the real world, not just by how severe it looks on paper. It combines exposure, exploit activity, asset importance, and automation potential to focus limited effort where attackers are most likely to succeed.

What's in the full article

Seemplicity's full blog covers the operational detail this post intentionally leaves for the source:

• How the reachability checks are applied during triage, including the evidence used to confirm or dismiss exposure.
• Examples of the runtime and network conditions that change a CVE from theoretical to actionable.
• The AI-assisted workflow used to attach exploitability evidence before a finding reaches engineering.
• How to structure response tiers when score, likelihood, and reachability do not point to the same priority.

👉 Seemplicity's full post covers the reachability checks, triage workflow, and evidence model in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and workload identity in the context of modern access control. It helps practitioners connect identity decisions to broader security programmes that rely on evidence, not assumptions.