What is the difference between reachability and attackability in application security?

Reachability asks whether code can get to a vulnerable function. Attackability asks whether an attacker can actually drive that path from a real ingress point, under the current controls, and achieve meaningful impact. The second question is the one that supports defensible prioritisation, because it ties the finding to abuse potential rather than theoretical execution.

Why This Matters for Security Teams

Reachability and attackability are often conflated in application security, but they answer different prioritisation questions. Reachability is useful for finding code paths that can be invoked. Attackability is more operational: can a real adversary exploit that path from a plausible ingress point, under the organisation’s current controls, and turn it into meaningful impact? That distinction is what separates a noisy backlog from a defensible risk queue.

This matters because teams that prioritise only on static reachability tend to over-assign effort to defects that are technically present but practically inaccessible, while missing routes that are exposed through authentication gaps, weak authorisation, exposed interfaces, or chained abuse. Current guidance across MITRE ATT&CK Enterprise Matrix and incident reporting practice favours looking at likely attacker paths, not just theoretical code execution. That is especially important when the application sits behind APIs, identity layers, or automation that changes the real ingress surface.

Attackability also becomes more important when findings are used to drive remediation SLAs, compensation controls, or executive reporting. A vulnerability that is reachable in test code but not attackable in production should not be treated the same as one that is exposed through a live authenticated workflow. In practice, many security teams discover that reachability created a sense of urgency only after production telemetry, abuse attempts, or incident response evidence showed the path was not actually exploitable.

How It Works in Practice

In practice, reachability analysis asks whether a sink, function, or gadget can be invoked from a caller or data flow of interest. That can be done with code-level static analysis, dependency tracing, call graph inspection, or runtime tracing. Attackability adds context that static analysis usually cannot prove on its own: is the input attacker-controlled, is the entry point exposed, are there preconditions such as authentication or session state, and can the path produce a security outcome that matters?

A practical workflow usually combines engineering and threat analysis:

• Identify the vulnerable code path and the real ingress points, including API routes, file uploads, message queues, and indirect integrations.
• Check whether the attacker can satisfy the preconditions, such as valid accounts, specific roles, or crafted payload structure.
• Validate whether existing controls like authZ checks, WAF rules, segmentation, or input validation stop the exploit before impact.
• Measure likely impact in the live environment, not just in a lab, including data exposure, privilege gain, integrity loss, or service disruption.

This is where environment evidence matters. Telemetry, asset exposure, and identity context often decide whether a finding is attackable. NIST control thinking in NIST SP 800-53 Rev 5 Security and Privacy Controls supports this shift because controls such as access enforcement, boundary protection, and monitoring change the real-world exploitability of a code path. For adversarial patterns, pairing application findings with CISA cyber threat advisories helps teams test whether the path matches current exploitation trends. These controls tend to break down in microservice environments with weak service-to-service authentication because internal paths become reachable from many more components than code review initially suggests.

Common Variations and Edge Cases

Tighter attackability analysis often increases review effort, requiring organisations to balance faster triage against deeper validation. That tradeoff is real, because a finding can be reachable in one deployment and not attackable in another, depending on network exposure, feature flags, tenant isolation, or identity controls.

There is no universal standard for this yet, so teams define attackability differently. Some use “internet-exploitable,” others include authenticated abuse, and some fold in chained paths where one weakness enables the next. Best practice is evolving toward explicit criteria: what ingress exists, what privileges are required, what preconditions must hold, and what outcome is plausible. Without that definition, one team’s high severity becomes another team’s ignore list.

Edge cases matter in modern systems. In serverless and event-driven applications, a function may be unreachable from the public internet but still attackable through a poisoned queue, a compromised workload identity, or a mis-scoped token. In AI-enabled systems, the concept extends further: a model endpoint may be reachable, but attackability depends on prompt injection, tool access, retrieval scope, and whether the system can actually be driven to leak data or perform unsafe actions. For that reason, current guidance increasingly treats attackability as a live-path question rather than a source-code question, which aligns with the broader threat-pattern thinking reflected in MITRE ATLAS adversarial AI threat matrix and recent incident analysis such as Anthropic.

Related resources from NHI Mgmt Group

• What is the difference between AI agent security and application security?
• What is the difference between permissions and authorization in application security?
• What is the difference between ASVS and MASVS for application security?
• What is the difference between software supply chain security and application security in agentic pipelines?