Notifications
Clear all
Topic starter
02/08/2026 11:52 am
TL;DR: Reachability can show that vulnerable code executes, but it cannot tell teams whether attacker-controlled input, real ingress, preconditions, and compensating controls make exploitation practical, according to Checkmarx. Attackability shifts triage toward demonstrable exploitability, which is the standard security teams actually need.
NHIMG editorial — based on content published by Checkmarx: Reachability is not exploitability, and attackability changes triage
Questions worth separating out
Q: How do teams know if a vulnerability is truly exploitable?
A: They validate it in the live environment using safe testing that shows whether an attacker can reach the condition, trigger it, and move beyond it.
Q: Why do reachability findings create noise in application security programmes?
A: Reachability creates noise because it answers whether code can be invoked, not whether an attacker can use it.
Q: What do security teams get wrong about attacker-controlled input in vulnerability triage?
A: They often assume that a vulnerable sink is dangerous whenever it is reachable in code.
Practitioner guidance
- Require exploitability evidence in triage: Ask teams to document attacker-controlled input, real ingress, control validation, and concrete impact before a finding is prioritised.
- Separate reachable from exploitable findings: Build workflow labels that distinguish code-path reachability from verified exploitability so engineering time goes to issues that can be abused in production.
- Map control breaks to the exploit chain: Record the exact point where authentication, allowlisting, sanitisation, or runtime hardening interrupts the path to impact.
What's in the full article
Checkmarx's full article covers the operational detail this post intentionally leaves for the source:
- The five-step attackability workflow used to validate attacker-controlled input, ingress, and exploitability
- Scanner-specific examples showing how SCA, SAST, IaC, container, and secrets findings are judged differently
- The evidence trail used to support a verdict of exploitable, not exploitable, or risk accepted
- How minimal-disruption remediation is documented alongside control validation and path narratives
👉 Read Checkmarx's analysis of attackability and reachability in application security triage →
Attackability vs reachability: are your triage controls decision-grade?
Explore further
02/08/2026 1:01 pm
Attackability exposes the reachability blind spot: Reachability tells teams that code can execute, but it does not prove that an attacker can drive the path to impact. The missing context is attacker control, ingress, and compensating controls. In practice, this is the difference between a finding that deserves immediate attention and one that only looks dangerous in a scanner. Security programmes that prioritise exploitable paths reduce noise and improve trust in triage.
A question worth separating out:
Q: What is the difference between reachability and attackability in application security?
A: 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.
👉 Read our full editorial: Reachability is not exploitability: why attackability changes triage
