Security teams should treat reachability as the first filter, then use EPSS to rank the reachable findings by near term exploit likelihood. That combination helps separate theoretical exposure from issues most likely to be weaponised. The practical goal is to focus remediation on the small set of vulnerabilities that are both exploitable in context and credible targets in the threat landscape.
Why reachability should come before exploit scoring
Reachability answers the most important first question: can the vulnerable code path actually be touched in the running environment? If not, exploit likelihood scoring becomes a lower priority signal. Once a finding is confirmed as reachable, EPSS helps sort the remaining set by how likely it is to be exploited soon, so remediation effort goes to exposures that are both real and credible.
That ordering matters because vulnerability queues often contain a mix of theoretical issues, dormant code paths, and active attack candidates. A reachability-first filter reduces noise from scans and lets teams distinguish dead code from attack surface, while EPSS adds a forward-looking layer for triage.
For organisations that need a concrete reference point for exploit likelihood, FIRST EPSS is the clearest probability-based model for near-term exploitation, and the NIST National Vulnerability Database remains the standard source for CVE and affected-product data that teams use to identify candidates worth testing for reachability.
How to combine code reachability with EPSS in triage
The practical workflow is straightforward: verify whether the vulnerable function, endpoint, library call, or configuration path is reachable in the deployed context, then rank the reachable set by EPSS. This keeps remediation aligned to actual exposure rather than abstract severity labels. A low-severity issue that is reachable and highly likely to be exploited may deserve more urgent action than a high-severity flaw that cannot be triggered from any meaningful path.
Reachability analysis is strongest when it is grounded in how the application is built and deployed. Static analysis, dependency mapping, runtime tracing, and package inventory each reveal different aspects of whether a flaw is truly in play. EPSS then helps separate the reachable items that are most likely to attract attackers from those that are technically reachable but currently less attractive targets.
- Confirm the vulnerable component is loaded, invoked, exposed, or otherwise reachable in the deployed environment.
- Exclude findings that are only present in dead code, unused dependencies, or paths blocked by current configuration.
- Within the reachable set, rank by EPSS to identify the most likely near-term exploitation candidates.
- Use remediation capacity on the small group of findings that combine exposure with credible exploit likelihood.
When reachability data is thin or inconsistent, treat the finding as partially triaged rather than fully deprioritised. In that case, the uncertainty itself is a reason to improve code and dependency visibility before making a firm risk decision.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | ID.RA-01 — Risk Assessment | Prioritisation of reachable vulnerabilities is a risk assessment activity. |
| PR.IP-12 — Vulnerability Management | Reachability filtering and EPSS ranking directly support vulnerability management. | |
| DE.CM-08 — Vulnerability Scans | Reachability analysis depends on scan results and asset exposure evidence. | |
| Recommendation — Assess reachable vulnerabilities by likelihood and impact to drive remediation order. Triage vulnerabilities using exposure context and exploit likelihood. Correlate scan findings with runtime reachability before escalating priority. | ||
| CIS Controls v8 | 7.1 — Establish and Maintain a Vulnerability Management Process | Reachability plus EPSS fits operational vulnerability management prioritisation. |
| 7.2 — Establish and Maintain a Remediation Process | The question is about selecting what to remediate first from a vulnerability queue. | |
| 2.1 — Inventory and Control of Software Assets | Code reachability depends on knowing which software components are present and active. | |
| Recommendation — Rank reachable vulnerabilities by exploit likelihood and fix the highest-risk items first. Use reachability and exploitability signals to sequence remediation work. Maintain accurate software inventory so reachable vulnerabilities can be identified quickly. | ||
Practitioner Guidance
What to prioritise: Start with reachable findings that also score meaningfully on EPSS, because that combination best reflects both exposure and attack pressure. If a vulnerability is unreachable in the current deployment, it should not compete with a reachable issue that already has strong exploit signals.
What to verify: Make sure reachability is assessed in the same runtime context that matters for the business, not just in source or package metadata. A finding can look benign in one environment and become relevant after a feature flag, route change, plugin load, or deployment drift.
Common mistake: Do not let EPSS outrank reachability. A high-likelihood score does not matter if the vulnerable path cannot be exercised where the asset actually runs. The useful triage sequence is reachability first, probability second.
Practitioner takeaway: The best remediation queue is not the longest list of severe CVEs, it is the shortest list of reachable issues that are both exploitable in context and likely to be targeted soon.
Related resources from NHI Mgmt Group
- How should security teams prioritise vulnerabilities when code scans and runtime data disagree?
- How should security teams prioritise vulnerabilities when exploit timelines are shrinking?
- How should security teams prioritise application vulnerabilities that appear across code and dependencies?
- How should security teams prioritise vulnerabilities when proof of concept code is public?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
