Attackability: Why Context, Not Reachability, Should Drive Remediation
好的,我现在需要帮用户总结一篇文章的内容,控制在100字以内。用户的要求是直接写文章描述,不需要特定的开头。首先,我得仔细阅读这篇文章,理解其主要观点。 文章主要讨论了安全行业中漏洞优先级的评估方法,从可达性(reachability)转向攻击性(attackability)。可达性只是判断漏洞函数是否能被代码执行,但并不考虑实际攻击的可能性。而攻击性则结合了AI驱动的分析,考虑了输入控制、真实入口点、前置条件和安全控制等因素,更准确地评估漏洞是否可被利用。 接下来,我需要将这些要点浓缩到100字以内。重点包括:传统方法的不足、Checkmarx Triage Agent引入的新方法、攻击性的定义及其优势。 可能会遇到的问题是如何在有限的字数内涵盖所有关键点而不遗漏重要信息。因此,我需要选择最核心的概念进行表达。 最终总结应简洁明了,突出从可达性到攻击性的转变及其带来的改进。 </think> 文章讨论了安全行业中从“可达性”到“攻击性”的转变。传统方法通过判断漏洞函数是否可执行来评估风险,但无法确定其是否可被实际利用。Checkmarx Triage Agent引入AI驱动的“攻击性”分析,结合输入控制、真实入口点、前置条件和安全控制等因素,更准确地评估漏洞是否可被利用。这种方法帮助团队做出更明智的安全决策。 2026-3-24 15:30:14 Author: checkmarx.com(查看原文) 阅读量:0 收藏

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: 

  1. 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. 
  2. 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. 
  3. 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. 
  4. 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. 
  5. 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


文章来源: https://checkmarx.com/ai-llm-tools-in-application-security/reachability-was-a-breakthrough-but-now-its-not-enough/
如有侵权请联系:admin#unsafe.sh