AI 模型已经能够在较少人工协助的情况下发现并利用软件漏洞，但“能指出可疑代码”距离“确认真实漏洞并修复”仍有很大差距。Google 开源的 Mantis 将漏洞发现、分诊、复现和修补组织成一套可自动化的流程，重点解决 AI 扫描中常见的误报、缺少上下文和修复不可验证等问题。
从扫描结果到安全结论
单纯让 AI 阅读代码，容易得到看似合理却无法复现的漏洞报告。来源摘要提到，松散的 AI 代码扫描可能产生大量幻觉漏洞，真实阳性率甚至低于 7%。Mantis 的思路是把多个环节串起来：
- 使用发现代理寻找潜在漏洞。
- 使用 critic 和 review 代理交叉检查结论。
- 在沙箱中复现漏洞，验证输入、影响和触发条件。
- 根据复现结果进行分诊，区分真实漏洞与不值得处理的问题。
- 生成补丁，并再次检查补丁是否真正消除了问题。
这里的关键不只是增加一个“审查代理”，而是让漏洞报告尽量落到可执行的证据上。一个漏洞是否成立，应该能够回答：攻击者需要什么权限？怎样触发？影响是什么？修复后原有触发路径是否失效？
Mantis 如何补足仓库上下文
大型仓库的安全分析经常受限于上下文窗口。Mantis 会分析仓库提交历史，从过去的安全修复中学习代码库的风险模式；当仓库没有现成的架构文档或威胁模型时，它还会自动构建这些信息。
它进一步创建分层的安全摘要树：先把单个文件压缩成目录级摘要，再向上汇总到仓库根目录。摘要称，这种方式在保留关键结构信息的同时，将 token 开销降低了 85% 以上。对实际使用者而言，这意味着代理可以把注意力集中到数据流、信任边界、认证逻辑和历史上容易出错的模块，而不是把整个仓库无差别塞进提示词。
自动生成的上下文仍然不是最终答案。团队掌握的业务规则往往更重要，例如“用户只能让自己的任务崩溃，不属于需要处理的安全问题”，或者“这个接口在生产环境一定经过网关鉴权”。这些规则应当明确提供给扫描流程，否则代理可能持续报告团队明确不关心的结果。
快速启动 Mantis
下面的命令会将仓库克隆到本地。路径需要替换为你的 Mantis 目录和待审查代码目录：
git clone https://github.com/google/mantis.git
# 之后在你使用的编码代理中提交类似提示词：
# I would like to use Mantis framework in /path/to/mantis \
# to review my code in /path/to/your/code, can you help me get started?
根据来源摘要，Google 内部曾使用这条提示词在多个代码仓库中发现真实漏洞。Mantis 仓库还包含沙箱选项，团队也可以按自身的构建、测试和部署方式实现沙箱。
可以这样规划一个最小可用的沙箱边界：
#!/usr/bin/env bash
set -euo pipefail
WORKDIR="$(pwd)"
SANDBOX="$(mktemp -d)"
trap 'rm -rf "$SANDBOX"' EXIT
# 假设项目提供 reproduce-vulnerability.sh，用于验证报告中的触发条件。
# 实际环境应进一步限制网络、文件系统和凭据访问。
cp -R "$WORKDIR" "$SANDBOX/project"
cd "$SANDBOX/project"
timeout 60s env \
HOME="$SANDBOX/home" \
NO_PROXY="*" \
./reproduce-vulnerability.sh
这只是一个可改造的示例，不等同于完整的安全隔离。生产环境应使用容器、虚拟机或其他受控执行环境，并限制网络出口、主机文件系统、云凭据、资源消耗和持久化数据。沙箱的验收标准也要写清楚，例如：指定攻击输入必须触发漏洞、退出码必须符合预期、补丁版本必须阻止同一触发路径。
让修复结果可验证
漏洞发现和补丁生成不应是两个互不关联的步骤。一个实用的工作流可以保存以下证据：
- 漏洞所在提交、文件和代码路径。
- 触发漏洞所需的输入、权限和环境。
- 沙箱中的复现命令及原始输出。
- 分诊结论和接受标准。
- 补丁内容以及补丁后的复测结果。
这样做可以避免“代理说已经修好”成为唯一依据。对于高风险问题，复现脚本应当在补丁前失败或触发漏洞，在补丁后明确通过；同时还需要运行项目现有测试，确认修复没有破坏正常行为。
当团队积累了一批经人工确认的漏洞、误报和修复案例后，可以使用新的 mantis-advise skill，让编码代理把这些经验用于日常开发，在代码第一次写出来时就减少重复问题。这比单独扩大扫描频率更有价值，因为知识会从安全审查环节回流到实现环节。
落地检查清单
采用 Mantis 或类似 AI 安全框架时，可以从以下边界开始：
- 为扫描器提供业务规则、信任边界和不处理的问题类型。
- 为每类漏洞定义可执行的复现标准和修复验收标准。
- 把发现、批评、复现、修复和复测分成可追踪的步骤。
- 默认在隔离环境中运行不可信代码和攻击输入。
- 保存复现证据，避免只依赖自然语言判断。
- 用人工确认的安全修复持续改进后续编码建议。
Mantis 的价值不在于让 AI 输出更多漏洞，而在于建立一条更接近工程现实的链路：理解仓库、提出假设、在沙箱中验证、过滤误报、提交修复，再用同样的证据确认结果。对于希望以机器速度扩大安全覆盖面的团队，这是一处相对清晰的起点，但沙箱边界、业务上下文和验收标准仍然需要由工程团队负责定义。