Google Mantis：AI 辅助找 Bug 需要什么才能真正有用

快速摘要：AI 安全工具需要验证闭环

Google Cloud 介绍的 Mantis 项目，展示了 AI 辅助应用安全正在走向哪里。它不是让模型扫描仓库后返回一长串可疑问题，而是把漏洞发现、分流、复现、去重和补丁验证组织成一个工作流。真正重要的并不是 Agent 能否取代安全工程师，而是它是否拥有仓库历史、威胁模型、隔离执行环境、可重复工具，以及能够判断修复是否有效的明确测试。

这会改变开发者选择工具的方式。最好的安全助手不一定是发出最多警告的那个，而是能帮助团队从一行可疑代码走到可复现的问题、可审查的补丁，以及回归缺陷已经消失的证据。

Mantis 想解决什么问题

Google Cloud 的 Mantis 介绍把 Mantis 描述为一个用于找 Bug 和修复 Bug 的开源 Harness。Mantis 仓库还包含面向安全分析的工作流和技能。实际意义是，Agent 获得了一个有结构的环境，而不是一个空白聊天框。

这是关键，因为安全发现很少只是文字生成问题。一次有价值的调查可能要理解功能如何变化，确认输入周围的信任边界，构造小型概念验证，在沙箱中运行测试，把候选补丁与原行为比较，并删除重复报告。每一步都需要不同证据。一个擅长解释代码的模型，未必擅长证明可利用性，也未必能判断补丁是否破坏了无关路径。

为什么仓库历史和威胁模型重要

静态扫描看到的是今天存在的代码。拥有仓库历史的 Agent 还可以看到权限检查为什么加入、哪个输入被认为不安全，以及过去的修复是否不完整。这些上下文有助于减少误报，也能优先处理真正影响边界的变更。

威胁模型又增加了一层问题：谁控制输入，攻击者能到达什么，哪个身份或数据可能受影响，以及成功利用会改变什么。如果缺少这些问题，Agent 可能把每个异常模式都标成高危，也可能因为代码在局部看起来普通而错过细微缺陷。

因此，AI 安全工具应展示证据，而不是只给出自信的分数。报告最好包含相关文件和调用路径、使用的假设、复现步骤、预期影响和分析限制。团队才能决定是修补、增加补偿控制，还是不处理。

复现是分水岭

Agent 安全流程中最有价值的部分，往往是安全地尝试复现问题。沙箱可以限制网络、凭据、文件系统和破坏性命令，同时允许 Agent 验证一个狭窄的假设。这样得到的结果比模式匹配更具体。

复现也让沟通更容易。开发者可以审查小型测试用例，安全人员可以确认行为是否越过信任边界，发布负责人可以要求补丁之后同一个测试仍然通过。流程留下的不是聊天记录，而是可以在后续继续使用的工程产物。

当然，并非每个漏洞都能自动证明。有些问题依赖生产配置、时间条件、身份策略，或多个弱控制的组合。这种情况下，正确结果应该是边界清晰、带有不确定性的假设，而不是编造一个看似完整的攻击。

选择 AI 安全工具前要检查什么

下载或采用 Agent 安全工具前，至少检查五条边界：

1. 权限： Agent 能否读取密钥、写入生产分支或调用外部服务？
2. 隔离： 复现是否在一次性环境中运行，并且网络和文件系统策略清楚？
3. 证据： 发现是否关联代码、测试、日志和可复现步骤？
4. 恢复： 人能否暂停、回滚或拒绝补丁？
5. 数据： 仓库、提示词和生成补丁会保留多久，是否用于训练？

选择软件时，完整工作流比页面上的“AI”标签更重要。如果你正在比较编码助手、安全扫描器、测试工具或仓库工具，可以浏览 BTTC 软件目录，重点看权限、集成、导出和审核控制。更多技术解释也可以查看 BTTC 博客。

常见问题：用 Agent 做应用安全

AI Agent 能取代安全工程师吗？

不能。它可以加快重复调查、生成测试并整理证据，但风险定义、假设验证、变更审批和生产环境判断仍需要人。

复现出的 Bug 就一定是高危漏洞吗？

不一定。复现只证明它在测试条件下能够发生，严重程度还取决于暴露范围、攻击者控制能力、受影响资产、所需权限和业务影响。

应该允许 Agent 自动合并补丁吗？

通常不应默认允许。更安全的边界是让 Agent 创建候选补丁和回归测试，再经过人工审查和独立检查。

结论

Google Mantis 指向一种更可信的 AI 辅助安全模式：Agent 需要收集上下文、验证有限假设、产出可审查证据，并在受控范围内确认修复有效。对于正在评估开发者工具的团队，最值得问的问题是：这个产品能帮助你证明并安全解决问题，还是只会再生成一张需要人工筛选的清单？