Notifications
Clear all
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.
NHIMG editorial — based on content published by Seemplicity: Vulnerability Exploitability, and how to tell whether a critical CVE is reachable
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.
Questions worth separating out
Q: How should security teams prioritise CVEs in production environments?
A: Prioritise CVEs by verified exposure, not just severity.
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.
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.
Practitioner guidance
- 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.
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.
👉 Read Seemplicity's analysis of vulnerability exploitability and reachability →
Reachability analysis for CVEs: what actually makes a flaw exploitable?
Explore further
19/08/2026 4:16 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Vulnerability exploitability depends on reachability, not just CVSS score
