Runtime reachability gap is the distance between a vulnerability that exists in theory and a path an attacker can actually use in a live environment. It is closed by linking scan results to API inventory, identity context, and ownership so teams can tell what is truly exploitable.
Expanded Definition
Runtime reachability gap describes the difference between a vulnerability that is present in code, configuration, or dependency data and a vulnerability that can actually be reached in a running system. In practice, the gap exists when scanners report issues without enough live context to show whether an attacker can traverse an API, service route, identity boundary, or network path to trigger the weakness.
For security teams, the concept is especially important in cloud-native and identity-aware environments, where exposure depends on deployed services, token scopes, runtime permissions, and workload connectivity. NHI Management Group treats this as a governance problem as much as a technical one: the evidence needed to decide exploitability often sits across application security, IAM, and asset inventory tools. That is why reachability analysis must combine findings with ownership, service topology, and control state, rather than relying on scan output alone. The closest control language appears in NIST SP 800-53 Rev 5 Security and Privacy Controls, where risk treatment depends on knowing which protections are actually in place and effective.
The most common misapplication is treating every flagged vulnerability as immediately exploitable, which occurs when teams do not verify whether the affected component is reachable from a real execution path.
Examples and Use Cases
Implementing runtime reachability analysis rigorously often introduces data integration overhead, requiring organisations to weigh faster prioritisation against the cost of maintaining accurate live context.
- A container image scan finds a vulnerable library, but the service containing it is never deployed, so the issue remains theoretical rather than exploitable.
- An internet-facing API includes a vulnerable endpoint, yet authentication blocks all unauthorised requests, reducing practical exposure unless a valid identity or token is compromised.
- A dependency flaw appears severe in a code scan, but the affected function is unreachable from current application routes, so remediation can be scheduled rather than emergency-driven.
- A cloud workload exposes a service only to internal subnets, and runtime telemetry shows no inbound path from the internet, narrowing the exploitability assessment.
- An NHI-backed automation workflow has over-privileged tokens, and the gap closes only after teams connect findings to actual token use, service ownership, and execution permissions.
For reachability-driven validation, security teams often pair scanner output with asset and control references such as NIST AI Risk Management Framework when automation or AI-assisted triage is involved, and with OWASP Top 10 for Large Language Model Applications when agentic or LLM-enabled components expand the attack surface.
Why It Matters for Security Teams
Runtime reachability gap matters because it determines whether remediation is focused on genuine exposure or on theoretical noise. When teams cannot distinguish between a reachable and unreachable weakness, they tend to waste time on low-value fixes while missing vulnerabilities that sit behind valid identities, exposed APIs, or active workflows. That creates avoidable risk in modern environments where attack paths are shaped by service-to-service trust, secrets, and non-human identities.
This is where the identity dimension becomes operationally important. A vulnerability may be harmless in isolation but become reachable once a service account, API key, or agentic tool permission provides the missing path. For that reason, NHI Management Group frames runtime reachability as a cross-domain issue spanning application security, IAM, PAM, and NHI governance. It is also closely related to the least-privilege logic reflected in NIST SP 800-207 Zero Trust Architecture, because attack feasibility changes as trust boundaries and access decisions change.
Organisations typically encounter the cost of a runtime reachability gap only after an incident review shows that a high-severity finding was either never reachable or was missed because the reachable path was not modelled.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM-03 | Risk decisions should reflect what is actually reachable, not just what scanners detect. |
| NIST SP 800-53 Rev 5 | RA-5 | Vulnerability scanning must be paired with analysis to determine real operational exposure. |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero Trust requires understanding paths and boundaries that make a weakness reachable. |
| OWASP Non-Human Identity Top 10 | NHI controls depend on knowing whether exposed tokens or service identities can reach the flaw. | |
| NIST AI RMF | AI-assisted triage must explain how it determined a finding is reachable in context. |
Use live reachability evidence to separate theoretical findings from exploitable risk during triage.
