Attackability

Expanded Definition

Attackability is a prioritisation lens that asks whether a discovered weakness can be converted into a working exploit in the environment where the system actually runs. For NHI Management Group, the term is most useful when it is treated as a practical score built from exploitability, reachability, and exposure window, rather than as a synonym for severity. A severe finding may be low in attackability if it is isolated behind network controls, requires conditions that are rarely present, or is only reachable through a short-lived path. By contrast, a moderate issue can become high attackability when it is externally reachable, consistently exposed, and easy to weaponise.

That distinction matters because attackability changes with context. Runtime permissions, authentication paths, secret handling, agent tool access, and deployment timing can all increase or reduce whether a weakness is usable in the real world. This is why defenders often pair technical findings with threat modelling and control verification, using sources such as NIST SP 800-53 Rev 5 Security and Privacy Controls to test whether compensating controls are actually in place. The most common misapplication is treating attackability as the same as severity, which occurs when teams rank findings by headline impact without checking whether the affected asset is reachable, exposed, and exploitable in production.

Examples and Use Cases

Implementing attackability rigorously often introduces more triage work, requiring organisations to weigh faster vulnerability closure against the cost of validating real-world reachability and exploit paths.

• A public-facing API vulnerability with an available exploit and no compensating control has high attackability because an attacker can reach it directly and act quickly.
• A server-side flaw in a segmented environment may have lower attackability if only a small admin subnet can reach it and the exposure window is short.
• A secret embedded in application code becomes more attackable when it is deployed to multiple environments and accessible through logs, build artefacts, or agent workflows.
• An AI agent tool invocation weakness may be highly attackable when the agent can call sensitive actions automatically, a pattern increasingly reflected in MITRE ATLAS adversarial AI threat matrix and emerging guidance from the Anthropic first AI-orchestrated cyber espionage campaign report.
• A remote code execution finding may look critical on paper, but actual attackability can fall if CISA-active advisories show it is mitigated by upstream patching, segmentation, or enforced authentication in the deployed stack.

In practice, teams use attackability to decide what needs immediate validation, what needs compensating controls, and what can wait for a scheduled fix. It is especially valuable when multiple findings share similar severity but differ sharply in exposure or reachability. Guidance in MITRE ATT&CK Enterprise Matrix is useful here because it helps analysts reason about how adversaries would chain access, execution, and privilege escalation in realistic conditions.

Why It Matters for Security Teams

Security teams use attackability to stop wasting time on findings that are theoretically serious but practically inert, and to focus scarce response capacity on weaknesses an adversary can actually use. That makes it valuable across vulnerability management, application security, cloud security, and NHI governance, where exposure is often shaped by secrets, token scope, service-to-service trust, and tool permissions. In identity-heavy systems, attackability is often the difference between a harmless misconfiguration and a credential path that can be turned into lateral movement or privilege escalation.

The concept also improves executive decision-making because it explains why two equally severe issues may require very different responses. In AI and agentic environments, attackability becomes even more important: a flaw is not just about whether it exists, but whether an agent, model-integrated workflow, or exposed tool can be driven into harmful action. Teams should treat attackability as a dynamic property that must be re-evaluated after architecture changes, new integrations, or control failures. Practitioners typically encounter the real cost only after an exposed weakness is chained into intrusion, at which point attackability becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• Residual attackability