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.
Editorial analysis by NHI Mgmt Group, based on content published by Checkmarx: “Attackability: Why Context, Not Reachability, Should Drive Remediation”.
Key questions
Q: What should teams do when a critical finding is not actually exploitable?
A: They should re-score it using environment context, document the compensating controls, and keep it in a tracked risk queue rather than treating it as an emergency.
Q: Why do reachable vulnerabilities still get overprioritised in security programmes?
A: Because many workflows stop at code-path existence and do not test whether an attacker can actually drive the path to impact.
Q: What are the signs that attackability triage is failing?
A: A common sign is when findings are ranked high only because a sink is present, even though the input is trusted, the path is internal only, or a control already blocks exploitation.
Practitioner guidance
- Define exploitability criteria for triage Require every high-priority finding to show attacker-controlled input, real ingress, and a credible impact path before it enters remediation queues.
- Map controls that break the chain Record which authentication checks, allowlists, sanitizers, or runtime controls stop the finding from becoming exploitable, and make that evidence part of the ticket.
- Separate reachable from exploitable findings Create distinct statuses for technically reachable code, operationally exposed code, and demonstrably exploitable code so engineering time is not spent on theoretical paths.
Bottom line: Reachability tells teams that code can execute, but it does not prove that an attacker can exploit the path in a real environment.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 1:01 pm
Reachability is a necessary signal, but it is not a triage standard. Many teams still confuse code execution paths with practical exploitation paths, and that produces both wasted engineering effort and missed risk. The better question is whether attacker-controlled input can actually traverse the controls that sit between exposure and impact. Practitioners should treat reachability as a screening layer, not a decision-grade verdict.
A few things that frame the scale:
- The average time to mitigate a leaked secret is 36 hours, highlighting the operational burden of manual remediation processes, according to the 2024 State of Secrets Management Survey.
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to the State of Secrets in AppSec.
A question worth separating out:
Q: How should teams decide whether a low-severity issue needs urgent remediation?
A: Teams should escalate a low-severity issue when it unlocks access to higher-value data, expands browser reach, or shortens an attack path. The right question is whether the finding helps an attacker connect otherwise blocked stages. If it does, its practical risk is much higher than the scanner score suggests.
👉 Read our full editorial: Reachability is not exploitability: why attackability changes triage