Topic starter
24/10/2026 8:53 pm
TL;DR: Most CVEs are not actually reachable in the deployed product, and Finite State says reachability analysis, paired with EPSS and threat intelligence, can cut up to 95% of the noise. Vulnerability governance improves when triage is based on reachable attack paths, not raw scanner output.
Editorial analysis by NHI Mgmt Group, based on content published by Finite State: “How Reachability Analysis Transforms Vulnerability Management”.
Key questions
Q: When should organisations treat a CVE as lower priority?
A: When the vulnerability is not reachable in the actual runtime path, has low exploit likelihood, and does not affect a critical business function.
Q: What are the signs that a vulnerability prioritization model is failing?
A: The clearest signs are long delays on known exploited vulnerabilities, tickets that lack ownership, duplicate findings across tools, and high-severity work that never maps to real attack paths.
Q: How should security teams reduce application security backlog noise without losing risk context?
A: Start by deduplicating findings across scanners, then enrich each issue with reachability, exploitability, and business context before routing it to an owner.
Practitioner guidance
- Classify findings by reachability before assigning remediation work Separate exploitable issues from theoretical ones by requiring a reachability check for high-volume vulnerability sets before they enter engineering queues.
- Combine exploit likelihood with attack-path context Use EPSS alongside reachability and threat intelligence so triage reflects both probability and exposure, not severity scores alone.
- Preserve decision logs for audit and compliance review Store the rationale, evidence, and ownership for any vulnerability deferred because it was unreachable in the product’s actual use case.
Bottom line: Vulnerability scanners can overwhelm teams with findings that are not actually exploitable, which makes prioritisation the real control gap.
Glossary terms: Reachability analysis, Exploit Prediction Scoring System, Vulnerability triage
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 6 days ago by NHI Mgmt Group
25/10/2026 11:13 am
Reachability is becoming the missing control layer between scanning and remediation. Traditional vulnerability management proves that a defect exists, but not that an attacker can use it in the deployed product. That leaves teams with volume instead of judgement, which is why remediation backlogs grow even as scan coverage improves. The governance gap is not visibility, it is exploitability context. Practitioners should treat reachability as the decision layer that turns detection into prioritisation.
A question worth separating out:
Q: How do compliance teams justify leaving some vulnerabilities unpatched?
A: They need documented evidence that the issue was not reachable in the specific product or use case, plus a record of who approved the decision and when it will be revisited. That makes the exception defensible to auditors and internal stakeholders while keeping ownership clear. Without that trail, deferred remediation becomes an unmanaged risk.
👉 Read our full editorial: Reachability analysis helps teams prioritise exploitable CVEs
This post was modified 6 days ago by NHI Mgmt Group