Why do reachable vulnerabilities still get overprioritised in security programmes?

Why reachable code is not the same as exploitable risk

Reachability tells you that a path exists in the codebase. It does not tell you whether the path can be driven in the deployed system, with the real inputs, network controls, identities, data states, feature flags, and compensating controls that exist in production. Programmes overprioritise these findings when they treat static reachability as if it were impact, instead of as one weak signal in a larger exploitability test.

That gap matters because security teams often inherit a backlog shaped by scanner visibility rather than attacker feasibility. If the workflow cannot distinguish “present in code” from “usable in the environment,” it will repeatedly elevate issues that are easy to describe but hard to exploit, while missing lower-volume findings that actually survive environment-specific checks.

Reachable findings become overprioritised when they are sorted by local severity, code proximity, or theoretical worst case instead of by validated attack chain. A better triage model asks whether the condition can be reached from a realistic entry point, whether required prerequisites are available to the attacker, and whether the resulting action changes state, exposes data, or enables follow-on movement. The CISA Known Exploited Vulnerabilities Catalog is a useful reminder that confirmed exploitation is a different class of evidence from mere presence.

Why this produces noisy backlogs and weak decisions

Overprioritisation creates a false sense of precision. Teams spend time debating the existence of a code path while the operational question, “Can this be turned into impact here?” remains unanswered. That leads to weak risk decisions because the programme is optimising for measurable findings volume rather than for likelihood and consequence in the real environment.

The result is also organisational drag. Engineering time gets consumed by remediation work that may not reduce exposure, while genuinely exploitable issues compete for attention with findings that only look severe in abstract. The cost is not just slower remediation, but lower trust in the programme, because developers quickly notice when security asks for fixes that do not change actual risk.

In practice, the problem often starts when code analysis, SAST output, or simple path discovery is treated as the final verdict. Those tools can be useful for finding candidate weaknesses, but they are not enough to establish whether the exploit chain survives authentication boundaries, authorization checks, rate limits, compensating controls, or production configuration. NIST Cybersecurity Framework 2.0 helps anchor this kind of triage in governed risk decisions rather than raw finding counts.

What a better prioritisation test looks like

The practical test is to move from “reachable in code” to “reachable, usable, and consequential in the environment.” That means validating the exploit chain against deployed controls, realistic identities or sessions, data sensitivity, and the likely attacker position. If a weakness cannot be exercised end to end, it should usually be tracked differently from a confirmed exploitable issue.

Good programmes separate candidate weakness from demonstrated risk by using evidence tiers. A static alert may justify review, but only a validated chain should drive top-priority remediation. When the exploit path depends on environmental assumptions that are not met, or when the path is blocked by controls that are actually enforced, the issue may still deserve backlog treatment, but not the same urgency as a condition that can be triggered today.

This is where control guidance becomes useful. ISO/IEC 27002:2022 Information Security Controls supports a control-first view of risk, while NIST AI Risk Management Framework is a reminder, even in adjacent programmes, that context and impact assessment should shape decisions rather than raw detection alone.

Risk and Threat Considerations

When reachable findings are overprioritised, the main risk is misallocation of scarce remediation capacity. The programme becomes easier to report on, but less accurate at distinguishing theoretical exposure from exploitable exposure, which can leave material attack paths under-resourced.

Failure mechanism: Static reachability, path enumeration, or scanner output is mistaken for exploitability, so the workflow escalates issues before validating whether the path is actionable in production.

Impact: Backlogs become noisy, remediation loses credibility, and higher-value fixes may be delayed because teams are busy treating code existence as proof of real-world risk.

Practitioner Guidance

What to verify: Treat a reachable finding as unproven until you can show the attacker entry point, required preconditions, and the exact control bypass or state change that produces impact. If any of those pieces are missing, downgrade the urgency until the chain is demonstrated.

Decision rule: Prioritise the issues that survive environment validation first, then the issues with the strongest plausible path to impact, and leave static-only reachability findings in a lower triage band unless they map to a known exploitation pattern or critical asset.

Practitioner takeaway: The most useful security programme metric is not how many paths exist, but how many paths can actually be driven to harm in the live environment.

Related resources from NHI Mgmt Group

• What do security teams get wrong about vulnerabilities that are not reachable?
• What do security teams get wrong about risk assessment in identity programmes?
• What do security teams get wrong about access review automation in CMMC programmes?
• What do security teams get wrong about RBAC in IGA programmes?