RSAC 2026创新沙盒 | ZeroPath：从告警堆积到可执行修复

ZeroPath由Dean Valentine（CEO，首席执行官）、Nathan Hrncirik（CIO，首席信息官）、Raphael Karger（CTO，首席技术官）和Etienne Lunetta（COO，首席运营官）联合创立，四位创始人照片如图1所示。公开资料显示，Dean Valentine是公司当前最主要的对外代表人物；创始团队则具有连续创业以及Tesla红队、Google安全工程等背景，这在一定程度上解释了ZeroPath为何将产品重点放在复杂业务逻辑漏洞、漏洞利用条件验证以及自动化修复推进等更贴近真实企业场景的问题上。2026年，ZeroPath入选RSAC 创新沙盒决赛，进一步提升了其在新兴应用安全赛道中的关注度。

图3给出了三种常见情形：A表示系统虽然引入了存在风险的组件，但业务代码并未调用漏洞代码，此时工具告警但该漏洞在代码中是死代码，并无威胁；B表示相关路径确实可达，但输入经过净化或受限，例如业务的输入字符串是固定的，无法满足使得服务器崩溃的正则表达式模式，却较难真正触发；C则表示业务代码直接调用了相关功能且缺乏有效防护，这时漏洞才更接近真实可利用状态。问题在于，传统工具通常更容易停留在“组件存在漏洞”这一层。

以根据订单编号查询数据库并返回订单详情为例，存在接口：GET /api/orders/{id}。从表面上看，该接口既不存在明显的注入风险，也未出现显式危险操作，SAST可能也不会告警。然而，真正决定该接口是否安全的关键，往往在于是否存在一条必要的业务约束：当前用户是否有权访问该订单。如果系统缺失了“订单必须属于当前用户”这一校验，攻击者便可能通过枚举id访问他人订单信息，这正是典型的不安全的直接对象引用（Insecure Direct Object Reference，IDOR）或更广义的访问控制缺陷，如图4所示。之所以难以检测，是因为工具不仅需要判断该id是否来自用户可控输入，还需要进一步理解系统中的授权语义，即“只能访问自己的订单”这一规则在具体代码路径中是否得到了正确实施，而这类约束在不同系统中的实现方式往往并不统一。

这一判断若置于实际开发场景中理解，其含义会更加具体：当产出更快、提交更碎、评审压力更大时，诸如校验缺失、默认配置不安全等问题也更容易在快速迭代中被忽略。

ZeroPath的核心主张是，不再让用户事后去拼接多套工具的检测结果，而是直接提供一个统一的应用安全分析视图，其官网用一句话概括：One Scanner. All of AppSec[26]。RSAC官方发布的ZeroPath入围公司介绍也特别说明：用一个人工智能原生引擎替代传统SAST/SCA/Secrets/IaC组合，目标是抓到更复杂的业务逻辑问题和可串联的漏洞链[1]。

ZeroPath在SAST页面强调的重点，反而是更贴近工程判断的那一步：它想做“从输入到敏感点”的追踪，并把业务逻辑与鉴权缺陷当作重点对象（缺失鉴权、不安全的直接对象引用、授权绕过路径、支付竞态等）[6]。可以将其理解为：ZeroPath并不满足于仅作为“语法检查器”，更强调对完整业务执行路径的分析——去看一条请求从哪进来、走过哪些校验、最后落到哪里，如图7所示。

如果工具能把“入口参数来自用户→没有用户/租户边界校验→直接读到订单数据”这条路径串起来，分析人员即可更快判断该问题是否已接近真实可利用漏洞。反过来，如果它只给一句“可能越权访问”，仍需依赖人工进一步审查代码路径。

软件供应链过去几年的改良方向叫可达性分析（Reachability Analysis）：用依赖图、调用路径去过滤掉“不可能走到的漏洞代码”[16]。近年来一些工作[27]出现了可利用性分析（Exploitability Analysis）:漏洞到外部输入可控的代码不仅仅存在代码调用链，调用链上的可控输入/可控条件还需要满足漏洞可利用的约束，具体如图8所示，这样的漏洞才值得投入分析。ZeroPath在其方案页面里也给出类似口径：通过“AI Reachability Analysis”把大量被标记的CVE收敛到少量“更可能真正可利用”的问题[7]。ZeroPath的表达更接近第二种——它想把SCA的输出从“这组件存在漏洞”推到“是否存在利用的风险”。

这一路线并非ZeroPath独有，而是近两年SCA领域较明显的演进方向[32]。公开资料显示，Semgrep在2025年已将可达性分析进一步区分为依赖级、函数级和数据流级三种深度[29]；Snyk在2026年官方文档中也明确将可达性分析定义为“应用是否调用了与漏洞相关的代码元素”[30]；Endor Labs则更进一步，直接在文档中区分可利用（Exploitable）、潜在可利用（Potentially Exploitable）和误报（False Positives）[31]。放在这个背景下看，ZeroPath强调的不只是“发现受影响组件”，而是试图借助大模型将判断进一步推进到“当前系统中是否具备实际利用条件”这一层。与之相比，Endor Labs公开强调的仍主要是基于静态分析的方法。这一差异具有较强的分析价值，因为它对应的就是告警积压问题的根因：团队很难投入足够精力逐个理解和审计每个漏洞的上百条代码调用路径的各个约束。

RSAC创新沙盒中该公司的简介中，它把Secrets与IaC直接写进了“替代栈”的范围[1]。ZeroPath的方案页面进一步强调：它会用上下文方式去减少误报，例如对Secrets做更智能的过滤，对IaC风险做识别与“合理忽略”[7]。这些说法在产品宣传里很常见，但如果放进“一体化引擎”的逻辑里，它的意义会更具体：

IaC告诉你“哪里对外暴露”，代码告诉你“暴露的入口能干什么”；Secrets告诉你“是否暴露了敏感凭据”，代码和权限链路告诉你“这些凭据可能对应哪些可访问资源”，如图9所示。

当前的新变化在于，越来越多工具开始尝试把AppSec的输出从“发现问题”进一步推到“推动修复”。ZeroPath的公开主张便是如此：它不希望自己只停留在扫描器角色，而是希望将漏洞检测、验证和修复建议进一步推进到开发流程中，尽可能转化为研发团队可直接审查的改动[9]；其SAST页面明确提到，会给出可读的修复建议并生成可直接审查合并的代码合并请求[6]。与之相呼应，Anthropic在2026年推出的Claude Code Security，也将发现漏洞并给出可供人工审查的定向补丁建议作为核心卖点，但其官方表述更强调与现有工具协同，而非直接替代整套AppSec栈。二者共同说明，应用安全工具的竞争焦点正在从谁能报出更多问题转向谁能更有效地缩短从发现到修复的路径。

从研究视角看，自动程序修复（Automatic Program Repair，APR）并不是新问题，但至今仍然受到测试完备性、验证成本、补丁泛化能力和复杂错误修复能力等多方面约束[25]。放在当前产品实践中，这意味着“给出PR”远比“给出告警”更难。ZeroPath在公开材料中更强调其能生成可合并PR的方向，但关于补丁如何验证、如何降低回归风险、在多语言和复杂框架下能覆盖到什么范围，公开信息仍然有限[4][6][21]。相比之下，Claude Code Security的官方表述更谨慎：它强调的是为人工审查生成目标代码的补丁，并在帮助文档中将其定位为安全审查与修复建议能力，而不是自动替代开发者完成合并决策。这种差异也说明，行业虽然都在把修复能力前移，但对“自动修复”的边界仍普遍保持保守。

而当前一批新工具的共同方向，是尽量缩短这条链路。GitHub用发现并修复（find and fix）[10]来概括代码扫描结果自动化修复的目标，即尽可能把发现结果直接转化为修复建议[11]；Anthropic则把Claude Code Security定义为帮助团队发现并修复传统方法可能遗漏的问题，并补充现有安全工作流；ZeroPath更进一步，将“检测、验证、修复建议和PR生成”打包为对外叙事的一部分。三者的差异在于：GitHub更像是在既有代码扫描体系上增加自动化修复，Claude Code Security更强调以推理能力补足现有工具并推进自动化修复处置，而ZeroPath的叙事则更接近“以统一引擎统筹发现、验证与修复”[8][9]。但无论路径如何变化，竞争方向已经比较清楚：谁能更少地产生噪声、更快地给出高可信度解释，并更顺畅地进入开发者的实际修复流程，谁就更可能在新一轮AppSec工具演进中占据优势。

基于其公开描述，笔者认为ZeroPath进入RSAC决赛的原因是其更接近‘LLM辅助规格/语义+程序分析做可复核推理’的路线，如图11所示：LLM负责补语义、补上下文、补规则；真正跑全仓库、能复核的推理，交给程序分析来做[4][10][11][17]。

要让静态分析回答“这条输入能不能一路走到敏感操作”，通常得先把代码变成一种更适合推理的结构。从分析视角看，其核心并非逐文件阅读代码，而是构建统一的图结构表示——节点是语句/变量/函数调用，边是控制流、数据流、语法结构的关系，很多工具会把这类结构叫作代码属性图（Code Property Graph，CPG）[19]。

ZeroPath在公开材料里提到过自己的流程是从抽象语法树（AST）开始，再构建所谓的“enriched graph”(原文，未说明图是如何丰富)，后面做发现、验证、补丁生成[4]。这一表述本身透露出较为明确的技术取向：至少它承认“只靠大模型读文本”不够，得先把代码变成可计算的结构，才能谈“链路”“路径”“可利用”。

近年来的代表性工作IRIS[17][18]说明了一条更可行的结合路径。IRIS利用大语言模型生成污点分析中的规则信息，并补充相关上下文分析，而针对整个代码仓库的推理仍由静态分析负责完成。换言之，LLM在这一框架中承担的并不是“替代程序分析直接审计代码”的角色，而是为静态分析补足传统人工规格难以完整维护的语义与规则信息。这样的分工具有两方面意义：一方面，它利用了LLM在代码语义理解、框架知识迁移和上下文补全上的优势；另一方面，它保留了程序分析在路径可追踪、结果可验证和整仓库推理上的确定性能力。结合ZeroPath公开材料中提到的抽象语法树、enriched graph、漏洞发现、验证与补丁生成流程来看，其技术路线很可能也更接近这一类“LLM补语义与规格，程序分析负责可复核推理”的混合模式，而不是单纯依赖大模型直接对整仓库进行黑盒式安全判断。

因此，ZeroPath能够公开强调“深度理解代码”“少噪声”“更像可利用的路径”，编者根据上面已有研究，认为其在enriched graph的基础上，ZeroPath构建了围绕代码语义理解、误报收敛和可利用路径分析统一的推理框架，并将SCA中的可达性分析/可利用分析分析纳入其中[5][7]。对于依赖漏洞的判断标准将从“组件是否包含已知漏洞”进一步转向“当前代码路径是否能够实际到达相关漏洞位置”，从而提升风险结论的可解释性与处置价值。

从行业实践看，GitHub的自动化修复之所以建立在CodeQL等静态分析底座之上，并在文档中反复强调审查与约束要求，恰恰说明自动修复能力不能仅依赖模型生成本身，而必须建立在工程化护栏与验证机制之上[10][11]。

结合ZeroPath现有公开信息来看，其整体方向与自动化修复的趋势是一致的：它不仅强调漏洞发现，也同时强调路径分析、结果验证和补丁生成[4][21]。不过，针对不同语言与框架的支持深度、动态特性的处理方式、跨语言场景下的检测能力，以及证据链能否做到一致且可复核，公开材料仍未给出足够细致的说明。因此，现阶段更稳妥的判断是：ZeroPath展示出了一条具有现实吸引力的技术路线，但其在复杂工程环境中的成熟度和适用边界，仍有待更多公开信息进一步验证[4][5][7]。