Snyk Evo Agentic AppSec 以安全代理取代扫描器队列
Snyk 推出了 Evo Agentic AppSec，其中包含五个专业安全代理，向多年来主导应用安全领域的“扫描—分诊”模式发起挑战。该系统旨在软件代理生成代码的同时，发现、预防、修复并验证漏洞。Snyk 的核心判断是：依靠人工操作的扫描器无法跟上自主开发的节奏。
这并不意味着 Snyk 希望由 AI 模型做出每一项安全决策。其架构将概率性推理与确定性分析结合起来，后者是指受既定规则约束、可重复执行的检查。提出修复方案的代理不应自行批准自己的工作。
这种区别使 Snyk Evo Agentic AppSec 与传统工作流直接形成冲突。传统工作流会通过仪表板、工单和拉取请求评论，将发现的问题交给开发人员与安全团队。Snyk 希望让代理完成大部分这类运营工作，使人员专注于设定政策、审查影响重大的变更以及处理例外情况。
这一公告也出现在竞争拥挤的市场中。Checkmarx、GitHub 以及新兴安全厂商都在既有开发工作流中加入 AI 辅助检测或修复能力。因此，Snyk 必须证明的不只是代理的可用性，还要证明协同工作的代理能够减少真实的漏洞积压，而不会以不可靠的发现结果或有风险的自动化变更来换取速度。
Snyk Evo Agentic AppSec 将 AppSec 转变为持续循环
真正重要的变化并非又一个 AI 扫描器。Snyk 试图自动化的是围绕扫描器展开的整个运营周期。
2026 年 10 月 15 日发布的 Evo Agentic AppSec 在预防、检测、审查、修复和验证环节协调专用代理。这些代理使用 Snyk 现有的代码、依赖项和安全情报系统，而不是用通用模型取代这些系统。
该产品系列包括 Evo Code Scanning Agent、Evo Dependency Firewall、Evo Agentic Security Review、Evo Remediation Agent 和 Evo Secrets Detection。每个组件分别应对软件创建或维护中的不同阶段。
Code Scanning Agent 将模型推理与静态分析相结合。Snyk 表示，这种组合旨在发现僵化模式匹配可能遗漏的授权失败和业务逻辑缺陷。这些说法仍需得到广泛客户验证，尤其是在大型且陌生的代码库中。
Dependency Firewall 承担预防性角色。它会在安装前阻止恶意或不合规的软件包，其中也包括为利用编程代理幻觉生成的名称而创建的软件包。这种攻击方法有时被称为 slopsquatting，即攻击者注册一个看似合理、但实际不存在的依赖项名称。
Agentic Security Review 会检查代码仓库，构建应用程序模型和威胁模型，并评估现有控制措施是否覆盖可信的攻击路径。这比将源代码与已知漏洞模式进行匹配更进一步，也使代码仓库上下文和架构理解的质量变得尤为重要。
Remediation Agent 处理新代码中的漏洞以及现有依赖项积压中的漏洞。发布时，它专注于 Snyk Open Source 发现的问题。Snyk 表示，可能导致构建失败的变更会提交给人工审批，而不会被自动合并。
Secrets Detection 覆盖从开发环境到持续集成阶段暴露的凭据。综合来看，这些组件构成的是自动化循环，而非五个彼此无关的助手。一个代理识别问题，另一个提出行动方案，独立机制则检查结果是否符合政策。
各项功能的可用性仍不均衡。Code Scanning Agent、Dependency Firewall 和 Agentic Security Review 面向部分客户处于实验性预览阶段。Remediation Agent 处于开放预览阶段。Secrets Detection 及相邻的 Evo 产品已全面可用。
这一限定至关重要。Snyk 公布的是一种广泛的运营模式，但其中几项关键组件仍在受限群体中测试。评估该平台的企业所考察的是仍在推进中的架构，而非其现有 AppSec 计划的成熟完整替代方案。
尽管如此，此次发布确立了明确方向。过去，安全工具会等待人员发起扫描、解读发现结果、分配责任并跟进修复。如今，Snyk 希望软件代理能够持续维护这一循环，即使没有安全专家在关注某个特定代码仓库时也是如此。
AI 开发正使安全团队承受运营压力
直接压力落在 AppSec 团队身上：其审查能力仍维持在人力规模，而代码生产正日益自动化。
传统应用安全假定存在可识别的检查节点。开发人员编写代码、发起拉取请求、接收扫描结果，并在部署前决定修复哪些问题。安全团队则调整政策、调查高风险发现，并追踪尚未解决的工单。
编程代理削弱了这种节奏。它们可以在一次会话中修改多个文件、安装依赖项、生成测试并创建拉取请求。因此，开发团队无需增加工程师便能更快地产生变更，而其安全审查能力却基本维持不变。
Snyk 表示，在上一年中，其客户环境中检测到的严重和高严重性发现增加了十倍。其产品数据据称显示，队列中每修复一个漏洞，大约就会新增八个漏洞。这些是厂商来源的数据，并非对整个软件行业进行的独立测量。
即便如此，潜在的能力问题仍然不难理解。当没有人能够验证、确定优先级或修复问题时，再发现一个潜在弱点的价值有限。包含更多告警的仪表板可能扩大积压，同时制造覆盖范围更广的表象。
Snyk 的回应是将安全工作前移到代码创建过程。编程代理处于活跃状态时即可进行预防。确定性扫描针对代码变更运行。更深入的审查会检查组装完成的应用程序及其业务上下文。已有漏洞则进入自动化修复队列，而不是无限期等待人工认领。
该公司此前已将同样的时机论述应用于 agentic development controls。Evo Agentic Development Security 管理编程代理所使用的工具、Model Context Protocol 服务器和操作。Model Context Protocol，即 MCP，为 AI 系统提供了一种连接外部工具和数据的通用方式。
此前的产品聚焦于代理如何运行。Evo Agentic AppSec 则聚焦于它们创建和维护的内容的安全性。这两个层面都很重要，因为安全代码并不能保证安全的代理行为，而受治理的代理仍可能生成存在漏洞的软件。
Snyk 报告称，其对近 10,000 个开发者环境的分析发现，运行 MCP 服务器的开发者中，每 12 人就有 1 人存在高严重性或严重问题。该公司还单独报告，在近 4,000 个经审计的代理技能中，有 36% 至少存在一个安全缺陷。这些发现来自 Snyk 自身的遥测数据和方法论，因此买方应询问样本如何选择以及发现结果如何确认。
竞争压力同样波及成熟的 AppSec 厂商。Checkmarx 于 2026 年 7 月发布了自己的 self-healing AppSec 代理。其方法同样强调在编程工作流中持续检测、修复和验证。
GitHub 则采取了互补路线，在 CodeQL 的基础上加入 AI-powered detections。这种组合将覆盖范围扩展到传统静态分析更难部署的语言和框架。
这些动向表明，主要竞争已不再是 AI 安全与非 AI 安全之间的竞争，而是厂商能否将模型推理与可靠分析、易于接入的工作流集成以及受控修复结合起来。Snyk 的差异化主张在于，一支协同的代理团队能够运行整个计划，而不只是协助处理孤立的发现。
这一主张给安全领导者带来的压力不亚于给厂商带来的压力。如果该模式有效，仅收集扫描结果的团队将显得日益低效。AppSec 负责人需要定义可接受的自动化范围、审批边界、证据要求和失败处理流程。
开发人员也面临相关转变。他们的角色将从手动解读每一个告警，转向审查建议的代码变更与例外情况。只有当建议附带足以支持快速、知情决策的证据时，这一转变才能节省时间。
Snyk 的核心机制将生成与验证分离
Snyk 最可信的设计选择，是将负责推理的代理与验证可重复安全属性的系统分离开来。
大型语言模型产生的结果具有可变性，因为它们生成的是可能的响应，而不是执行固定的分析路径。这种灵活性有助于解读架构和业务逻辑，但也意味着同一份代码在重复审查中可能产生不同的发现结果。
Snyk 的 VulnBench JS 1.0 研究说明了这一问题。研究人员反复对 JavaScript 测试样例运行基于模型的审查，并将结果与 Snyk Code 参考集进行比较。在未匹配的发现中，49.7% 仅出现在五次运行中的一次。
这一统计并不意味着每一项仅出现一次的发现都是误报。该研究识别出模型发现了扫描器参考集之外可能存在弱点的案例，也发现模型报告了看似漏洞代码、却缺乏可执行 sink 的案例。
关键启示在于互补性。模型推理可以注意到依赖上下文或不熟悉的失效模式。确定性的静态应用安全测试能够重复枚举已知的数据流和 sink。在该基准测试中，任何一种方法都无法覆盖所有相关弱点。
研究中规模最大的、近似真实应用的测试样例清楚展现了这种张力。某个模型配置在多次运行中保持一致，但相对于 Snyk 参考发现仅达到 40% 的 F1。它反复遗漏系统化分析能够枚举的路径遍历和资源限制问题。
Snyk 据此拒绝以纯模型作为安全基础。其代理将确定性引擎作为工具调用，并将其输出作为约束条件或验证信号。随后，独立的验证路径会评估发现结果和拟议修复方案。
这种分离类似于一项基本工程控制：做出变更的组件不应是唯一决定该变更是否安全的组件。独立测试、构建系统、扫描器和策略门禁会提供不同的证据。
对于依赖项修复，Snyk 表示，可合并的修复必须消除漏洞，同时确保项目仍能构建。其 VulnBump 基准测试据称显示，在这一标准下，未辅助模型的成功率为 59.6%。Evo Remediation Agent 借助 Snyk 上下文和验证达到了 90%。
这些数字令人鼓舞，但仍属于公司自行发布的基准测试结果。代码仓库选择、依赖复杂度、构建条件以及“漏洞已修复”的定义都会影响性能表现。受控基准测试无法证明在每一种企业环境中都能达到相同的成功率。
不过，这种架构确实解决了智能体自动化中的一个真实弱点。让同一个模型提出、审查并批准变更，会造成相关性失效。审查者可能继承导致错误变更的假设或盲点。
独立的确定性检查能够在其可衡量的属性上降低这种相关性。构建成功可以表明补丁是否能够编译。依赖解析可以确认存在漏洞的版本是否已被移除。静态分析可以判断已知的源到汇路径是否仍然存在。
还有一些属性难以通过简单验证来确认。补丁可以通过构建，却仍然改变业务行为。它可以移除一条利用路径，同时引入另一条。它可以满足扫描器要求，却不符合组织的威胁模型或运营需求。
因此，Snyk 让人类“在环监督”。这一表述指的是由人来监督政策和关键决策，而非手动执行每一项操作。对新引入缺陷的预防可以自动进行，而对已部署代码的变更则会接受更严格的审查。
这一边界合理，但很难标准化。一个代码仓库中的低风险库升级，在另一个仓库中可能具有运营敏感性。企业需要基于服务关键性、测试质量、数据暴露情况、部署可逆性和监管义务来制定政策。
因此，真正的产品不只是智能体的集合。它还是一套编排与证据系统，用于决定何时可以接受自主行动。Snyk 的确定性引擎为这一系统提供了比单纯自由形式模型提示词更坚实的基础。
智能体团队仍需赢得企业信任
最大的未知并不在于智能体能否生成修复方案，而在于组织能否在复杂的生产环境中验证它们的判断。
三项核心组件仍处于实验性预览阶段。这限制了有关其企业级可靠性的现有证据。预览用户可以测试工作流程，但买家尚未获得关于接受率、回滚频率或长期积压减少情况的广泛公开数据。
Snyk 的公告将“积压清零”描述为可实现的目标。这一说法颇具吸引力，因为累积的漏洞会消耗工程团队的注意力，并扩大潜在攻击路径。但待办队列在数字上归零，并不自动意味着应用已经安全。
智能体可能关闭低价值发现项，而复杂的授权缺陷仍未解决。政策可能过度压制问题。修复系统可能生成可合并的变更，却以传统测试无法检测的方式改变行为。
基准测试证据也存在边界。VulnBench 使用经过选择的 JavaScript 测试样例和一套 Snyk Code 参考集。这使其适合研究可重复性和互补性检测，但并不代表每种语言、框架、代码仓库规模或应用架构。
VulnBump 也有同样的局限。依赖升级是很有价值的修复目标，因为包版本和构建结果能够提供可衡量的信号。业务逻辑修复、访问控制变更和分布式架构修复则带来更困难的验证问题。
Agentic Security Review 面临的任务尤其严苛。威胁建模依赖于对资产、信任边界、用户角色、部署假设和可信对手的理解。代码仓库通常只包含其中一部分信息。
缺失的上下文可能造成虚假的信心。智能体或许能够正确解读代码，却误解周边基础设施。它可能不知道某项服务处理受监管信息、依赖未记录的网关，或支持某种非同寻常的内部工作流程。
因此，组织必须评估证据质量，而不只是发现数量。有效的输出应识别相关代码路径、解释威胁场景、说明拟议变更，并展示哪些独立检查已经通过。
可审计性同样重要。安全团队需要保留记录：智能体观察到了什么、调用了哪些工具、获得了哪些政策许可，以及由谁批准最终行动。这些历史记录在事件处置、合规审查和存在争议的变更中至关重要。
更广泛的智能体风险框架强调了目标劫持、工具滥用、身份滥用、受污染的供应链和意外代码执行等威胁。这些风险既适用于防御型智能体，也适用于它们所检查的应用。
安全智能体可以访问敏感源代码、问题跟踪器、构建日志、软件包注册表和部署系统。过多权限会扩大其潜在影响范围。薄弱的工具边界可能将一个有帮助的审查者变成高权限自动化通道。
Snyk 的独立性原则有助于验证，但独立并不必然意味着隔离。两个组件可能共享数据源、政策、基础设施或有缺陷的假设。买家应询问，“独立”在技术和运营层面具体意味着什么。
他们还应测试对抗性条件。被操纵的代码仓库文本能否影响审查智能体？恶意软件包元数据能否误导其推理？系统是否能够区分不可信指令与合法的项目文档？
如果设计不佳，人类审查也会形成另一项瓶颈。如果智能体在没有优先级排序的情况下生成大量拉取请求，开发人员将面临另一种形式的告警疲劳。接受率会下降，团队也可能机械地批准变更。
最强的部署方式会设定狭窄的初始边界。团队可以从有全面测试支持的依赖修复开始，再逐步扩展到更依赖上下文的修复。随着服务关键性和变更复杂度上升，批准政策应更加严格。
团队还需要有意义的基线。在采用自主修复之前，他们应衡量当前修复时间、重新打开的发现项、构建失败、已接受的修复以及漏洞存续时间。没有这些基线，忙碌的智能体可能看似高产，却没有降低风险。
可搜索的安全决策记录同样有用。工程团队可以在可搜索知识库中保留威胁模型、被拒绝的变更、测试证据和事件经验。这些上下文即使在自动化发生变化时，也能支持人工审查者。
因此，应将 Snyk Evo Agentic AppSec 视为一套受控的生产系统来评判。令人印象深刻的演示不如来自多样化代码仓库的可重复证据重要。由于该系统作用于组织所依赖的同一份代码，其证明责任也更高。
竞争焦点在于控制点
Snyk 正在争夺自主代码生成与生产环境之间的控制层，而不只是成为另一个漏洞发现来源。
传统扫描器占据交付管道中的特定环节。它们在编辑器中、拉取请求期间、持续集成阶段，或面向已部署应用运行。随后，发现项通过既定审查流程交给相关人员处理。
智能体驱动的开发改变了杠杆所在的位置。编码智能体可以选择软件包、调用外部工具、编辑大量文件，并在传统管道启动前提交变更。仅部署在生成之后的安全控制，会承接此前所有上游决策。
Snyk 正将其控制扩展到整个序列中。Dependency Firewall 会在软件包安装前进行干预。Agentic Development Security 管理工具和 MCP 连接。Code Scanning Agent 分析生成的代码。Remediation Agent 同时处理新发现项和历史积压。
Continuous Offensive Security 从对手视角测试正在运行的应用。Snyk 表示，该组件作为独立评审者运行，而不是让修复智能体自行批准其输出。
这一结构形成了连贯的平台叙事。但它也可能增加对单一供应商遥测数据、政策和风险解释的依赖。企业应审查证据和工作流历史是否能够在不同工具之间保持可移植性。
Checkmarx 正通过自主分诊、开发者辅助、修复智能体和 AI 资产治理追逐类似的控制点。GitHub 能够深度集成安全能力，因为它已经托管源代码、拉取请求、工作流和开发者身份。
专业的进攻性安全供应商则从另一方向切入市场。它们利用智能体探索应用、验证可利用性并复现攻击者行为。其优势可能在于对抗性测试的深度，而非完整生命周期的编排。
Snyk 现有的客户基础为其带来分发优势。该公司称，超过 4,800 家客户使用其确定性引擎，而超过 1,600 家客户已采用 Snyk Studio。现有集成能够降低引入智能体的运营成本。
然而，既有地位并不能保证智能体会被采用。安全与平台团队将比较修复质量、语言覆盖范围、执行权限、工作流干扰程度和证据透明度。他们还会考虑原生代码仓库控制是否已经满足足够多的需求。
胜出的模式可能仍将是混合式的。当目标属性可以被形式化追踪或反复测试时，确定性系统非常有效。当安全工作需要上下文、优先级判断或适应能力时，基于模型的智能体则更有用。
面对模糊风险，人类判断仍然不可或缺。针对公共服务的政策例外，可能不同于内部工具中的同一例外。授权变更可能影响源代码中并未体现的合同要求。
这就是为什么 Snyk 的主要对手是一种工作流，而不是某一家公司。旧有工作流假设安全专业人员可以手动操作工具并处理由此产生的队列。Snyk 押注的是：当自主智能体持续产生变更时，这一假设将会失效。
竞争对手可以接受这一前提，同时质疑 Snyk 的具体实现。他们可以主张采用代码仓库原生自动化、更深入的运行时证据、专业化自主测试，或供应商中立的编排方案。
这种竞争有利于买家，因为它将注意力从聊天机器人界面转向可衡量的控制措施。有用的安全智能体应缩短修复时间，而不是掩盖不确定性。它应产生能被另一套系统或其他人质疑的证据。
控制点将属于那个赢得行动许可的平台。检测只能带来可见性。修复需要信任，而自主修复则需要更强的测试、政策、回滚和问责组合。
三个信号将显示 Snyk 的押注是否奏效
下一阶段取决于客户证据、更广泛的可用性，以及独立验证能否经受真实生产复杂性的考验。
第一个信号是预览组件向正式全面可用性的推进。Code Scanning Agent、Dependency Firewall 和 Agentic Security Review 目前仍处于受限访问状态。更广泛的发布将表明 Snyk 已稳定其工作流、控制机制和支持要求。
细节比名称更重要。买方应关注有文档支撑的语言覆盖范围、代码库限制、支持的开发代理、审批选项、审计导出能力以及回滚行为。清晰的运营边界将增强 Snyk 对该系统已具备持续开展安全工作的主张。
第二个信号是客户报告的修复表现。Snyk 已发布基准测试结果，但企业需要生产环境指标。可参考的证据包括被接受的修复率、构建失败率、重新打开的漏洞、中位修复时间，以及待处理积压问题存续时间的变化。
仅仅发现数量下降并不足够。团队应确认高风险暴露是否减少，以及自动化修复是否能稳定留在生产环境中。跨多种语言和应用类型的证据，比单个经过优化的依赖项工作流更能增强说服力。
较低的接受率会削弱这一论点。若庞大的审查负担只是将工作从安全分析师转移给开发人员，同样如此。只有在维持可接受风险的同时降低总体运营成本，该系统才算成功。
第三个信号是竞争对手和平台所有者如何应对。Checkmarx 已提供基于代理的预防和修复功能，而 GitHub 正在将 AI 检测与确定性的 CodeQL 分析相结合。更多集成式审批、验证或自主修复功能的出现，将证实这一控制点正变得具有战略重要性。
如果代码库原生替代方案以更少的集成实现相当效果，竞争对手的进展仍可能削弱 Snyk 的地位。反过来，混合推理与确定性验证获得广泛采用，将验证 Snyk 的架构论点。
安全团队不应等到市场赢家出现后才测试这一底层模式。他们可以界定一组范围有限的代码库，建立基线指标，限制权限，并将代理建议与现有审查结果进行比较。
核心问题很实际：Snyk Evo Agentic AppSec 是否能在不掩盖决策过程的前提下，更快消除已验证的风险？应要求供应商提供可复现的证据，而不仅仅是演示。对被拒绝的修复方案，也应像对被接受的方案一样仔细追踪。如果独立验证、受控权限和人工问责能够经受生产负载的考验，安全代理就能成为真正的运营者。如果这些控制措施随着覆盖范围扩大而减弱，熟悉的扫描器队列只会被更快但透明度更低的队列取代。
