For years, reachability has been the security industry’s go-to approach for vulnerability prioritization. Instead of flagging every vulnerable dependency, the idea was to determine whether an application could actually reach the vulnerable function. This marked a meaningful step forward in application security, shifting focus to code that executes in production. But reachability is not exploitability. A function can be reachable and still pose no practical risk if it sits behind authentication, processes only trusted inputs, or is mitigated by runtime controls. Reachability confirms that code can run, not that an attacker can abuse it. Modern software development requires more than execution analysis. Checkmarx Triage Agent addresses this head on with Attackability: AI-driven triage that traces attacker-controlled inputs from real ingress points to potential impact and verifies which controls prevent exploitation – and which do not. The result is triage based on demonstrated exploitability, not theoretical reachability. What Reachability Actually Tells You Most SCA tools define reachability at the function level: is there a path from your code to the vulnerable function? If yes, the finding is flagged as reachable. If not, it’s deprioritized. That’s useful, but it’s also incomplete. Here’s what reachability doesn’t tell you: Whether the input reaching that function is attacker-controlled, or only comes from trusted internal sources Whether there’s a real ingress point (a public API, a webhook, a file upload) that a real attacker could use Whether required preconditions exist, like a specific protocol behavior or a privileged network position Whether controls on the path, such as a safe parser, an authentication check, or an allowlist, already break the exploit chain What the actual impact would be: RCE, data exposure, privilege escalation, or something else A finding can be technically reachable yet completely unexploitable in production. When that happens, engineering time is wasted for no reason, and real risk competes for attention. Security teams don’t need to know “can this function run?” they need to know “can an attacker exploit this in our application, given our ingress points, our controls, and our runtime environment?” That’s the difference between reachability and attackability. How Attackability Works Checkmarx Triage Assist introduces Attackability: AI-driven triage that traces attacker-controlled input from real ingress points to potential impact, and validates which controls prevent exploitation and which do not. Attackability follows a consistent five-step flow regardless of the scanner type: Identify the vulnerable capability and candidate sink. Confirm what the vulnerable library, pattern, or API surface is, and form an initial hypothesis about how exploitation would occur. Prove or disprove a real execution path. Trace whether the vulnerable code path is reachable in the repository, including direct calls, indirect framework behavior, and configuration-driven invocation. Validate attacker control and real ingress. Identify how data enters the system (API endpoints, file uploads, queues, webhooks, scheduled jobs) and whether an external attacker can actually influence the data that reaches the sink. Validate controls and preconditions. Check whether security controls apply on the relevant path: safe parsing, allowlists, auth boundaries, sanitization, runtime hardening. Document any required preconditions, such as a MITM position or specific deployment settings. Conclude exploitability and explain impact. Give a clear verdict (exploitable, not exploitable, or risk accepted with rationale), state the concrete impact, and provide a minimal-disruption remediation This moves the conversation from “is this reachable?” to “is this exploitable?” Not Just for SCA Attackability isn’t limited to dependency finding; it applies the same reasoning across most scanner types. For SAST findings, it connects a detected code pattern to a real exploit chain by asking whether there’s a genuinely attacker-controlled source, whether the data flow reaches a dangerous sink, and whether controls on the path already prevent exploitation. A tainted data flow that never crosses an authentication boundary, or that’s constrained by an allowlist, can be reachable in code without being attackable in production. For IaC and cloud misconfigurations, it evaluates whether a configuration issue is externally accessible and whether it creates a realistic path to impact, factoring in exposure surfaces, identity controls, and network controls. For container findings, it assesses whether a vulnerable package is used at runtime, whether the container runs with elevated privileges, and whether the affected component is exposed through a reachable service. For secrets detection, it evaluates whether the credential is valid, scoped, and exposed in a way an attacker can actually leverage, factoring in repository visibility, rotation state, and downstream blast radius. What Makes the Output Credible The Attackability data is useful precisely because it’s verifiable. It includes concrete code references showing how the library or sink is used, a path narrative describing the chain from ingress to sink to impact (including where the chain breaks if the finding isn’t exploitable), explicit control validation, and a precise impact statement. This matters more than triage speed. It means developers can see exactly how the issue is triggered and what minimal change breaks the chain. It means risk acceptance decisions are documented with evidence, so security and engineering teams are aligning on facts (not assumptions). Reachability Is Just a Starting Point Reachability made vulnerability data more relevant. But reachability is not enough. Checkmarx Triage Assist’s Attackability adds attacker context, environmental context, and control validation, turning a reachability result into something a team can actually make a decision on. Ready to go deeper? Read the Agentic AI Buyer’s Guide to understand what separates decision-grade triage from theoretical analysis or watch the Checkmarx Triage Assist demo video to see Attackability in action. Tags: Agentic AI AI AI generated code checkmarx one developer assist
