Topic starter
19/08/2026 3:35 pm
TL;DR: CVSS and EPSS describe severity and likelihood, but neither can tell you whether a vulnerability is reachable in your own environment, according to Seemplicity research, so teams need exploitability validation and reachability analysis before escalating every critical score. The practical shift is from score-led triage to evidence-led vulnerability management, where runtime exposure and compensating controls determine priority.
Editorial analysis by NHI Mgmt Group, based on content published by Seemplicity: “Vulnerability Exploitability: Is That Critical CVE Reachable?”.
Key questions
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.
Q: Why do high CVSS scores often fail to reflect real business risk?
A: CVSS measures technical severity, but it does not know whether a vulnerable system is business-critical, internet-facing or protected by segmentation.
Q: What are the signs that vulnerability triage is becoming a security bottleneck?
A: Common signs include engineers spending most of their week validating noisy submissions, a backlog of unreviewed reports, frequent duplicate closures, and slow handling of truly critical findings.
Practitioner guidance
- Validate runtime presence before escalation Check whether the vulnerable code, library, or service is actually deployed in production and invoked at runtime before raising the incident priority.
- Map network reachability paths Trace the exact paths an attacker would need, including public exposure, segmentation boundaries, firewall rules, and access restrictions.
- Attach evidence to every triage verdict Record why a finding is or is not reachable, including what was checked, what blocked access, and what runtime evidence supported the decision.
Bottom line: CVSS and EPSS are useful signals, but they do not prove that a vulnerability can be reached in a specific environment.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
19/08/2026 4:16 pm
Reachability is the missing governance layer in vulnerability management. Score-based triage assumes that severity and exploitability move together, but operational reality is more conditional. Reachability adds the question that scores omit: whether the vulnerable code is actually present and exposed in the live environment. Practitioners should treat that as a governance control, not a nice-to-have refinement.
A question worth separating out:
Q: What should teams do when a vulnerability is confirmed unreachable?
A: Document the evidence, keep the verdict tied to the asset and environment, and place the finding on a review cycle rather than an emergency patch path. Unreachable does not mean forever safe. A deployment change, route change, or control change can make the same flaw exploitable later.
👉 Read our full editorial: Vulnerability exploitability depends on reachability, not just CVSS score