Google Mantis：用可复现证据压低 AI 漏洞扫描的误报率

预计阅读时间：7 分钟

Google 开源了 Mantis，一个覆盖软件漏洞生命周期的 AI Agent 框架。它处理的不只是“发现可疑代码”，还包括验证漏洞、构造复现方式以及辅助修复。这个方向直指 AI 代码扫描的核心问题：模型能够生成大量看似合理的安全报告，但其中可能混有误报，甚至完全由幻觉产生的漏洞。

从“发现问题”转向“证明问题”

传统静态扫描器通常根据数据流、规则或模式输出告警。引入大模型后，扫描器更擅长解释上下文，也能发现规则未覆盖的问题，但自然语言推理本身不能成为漏洞成立的证据。

一条高质量漏洞记录至少需要回答四个问题：

哪个输入能够到达危险操作？
攻击需要什么权限、配置和运行环境？
是否存在稳定、可重复执行的触发步骤？
修复后，同一复现步骤是否不再成功？

Mantis 所体现的关键变化，是把这些步骤组织成一个连续的 Agent 工作流。发现阶段可以保持较高召回率，而验证阶段用代码执行、测试结果和环境证据收紧结论。最终进入开发者队列的，不应只是一段模型解释，还应包含可以检查的证据链。

漏洞生命周期需要明确的状态门

团队可以把扫描结果划分为 suspected、reproduced、fixed 和 verified 等状态。状态变化必须由可观察结果触发，而不是由模型再次判断自己的结论是否正确。

例如，Agent 可以提出攻击路径并生成复现测试，但只有测试在受控环境中稳定触发问题，记录才能进入 reproduced。补丁生成后，还要同时运行复现测试与正常回归测试：前者确认攻击失效，后者防止修复破坏正常功能。

这种设计也让失败更容易解释。无法复现不一定意味着绝对安全，可能是缺少依赖、测试夹具不完整或漏洞只在特定配置下出现。因此系统应保存命令、退出码、标准输出、标准错误、提交版本和环境信息，而不是简单地把结果压缩成“有漏洞”或“无漏洞”。

可以这样实践：给 Agent 输出增加可执行验证门

下面是一个最小验证器，用来演示如何要求扫描结果携带结构化复现命令。它不是 Mantis 的官方接口，而是可以接入 CI 或内部 Agent 工作流的简化模式。运行前，把 reproduce.command 替换为项目中真正的安全测试命令。

mkdir -p agent-validation && cd agent-validation

cat > finding.json <<'JSON'
{
  "id": "DEMO-001",
  "summary": "Untrusted input may reach a dangerous operation",
  "reproduce": {
    "command": ["python3", "-c", "print('reproduced: controlled test'); raise SystemExit(0)"],
    "timeout_seconds": 10
  }
}
JSON

cat > validate_finding.py <<'PY'
import json
import subprocess
import sys
from pathlib import Path

finding = json.loads(Path("finding.json").read_text(encoding="utf-8"))
reproduce = finding.get("reproduce", {})
command = reproduce.get("command")
timeout = reproduce.get("timeout_seconds", 30)

if not isinstance(command, list) or not command:
    raise SystemExit("invalid finding: reproduce.command must be a non-empty array")

try:
    result = subprocess.run(
        command,
        capture_output=True,
        text=True,
        timeout=timeout,
        check=False,
    )
except subprocess.TimeoutExpired:
    raise SystemExit("validation inconclusive: reproduction timed out")

print(result.stdout, end="")
print(result.stderr, end="", file=sys.stderr)

if result.returncode == 0:
    print(f"VERIFIED {finding['id']}: reproduction succeeded")
    raise SystemExit(0)

print(f"UNVERIFIED {finding['id']}: reproduction failed with {result.returncode}")
raise SystemExit(1)
PY

python3 validate_finding.py

这里约定复现命令返回 0 表示漏洞已在受控测试中触发。实际项目可以把命令换成 pytest tests/security/test_issue_123.py、集成测试脚本或容器内的 HTTP 探测程序。修复验证阶段则应反转断言：补丁应用后，同一个攻击输入必须无法触发漏洞，同时完整回归测试仍然通过。

不要直接执行模型生成的任意命令。生产实现应使用临时容器、只读源码挂载、无特权用户、网络限制、CPU 和内存配额，并对命令及可访问路径设置白名单。漏洞复现往往会主动处理恶意输入，隔离边界本身就是框架可信度的一部分。

接入现有研发流程时关注什么

采用这类框架时，不宜只统计“发现了多少漏洞”。更有意义的指标包括确认误报率、成功复现率、人工确认耗时、修复后的回归失败率，以及从首次发现到验证关闭的时间。

落地时可以从一个代码库和一种高价值漏洞类型开始，为每条发现保存结构化证据，并要求关键状态转换由确定性工具完成。Agent 适合生成假设、组织上下文和尝试修复；编译器、测试框架、沙箱以及人工安全评审仍负责提供最终约束。Mantis 的价值不只是增加一个扫描器，而是把漏洞报告从“听起来可能成立”推进到“能够复现、修复并再次验证”。

Google Mantis：用可复现证据压低 AI 漏洞扫描的误报率

从“发现问题”转向“证明问题”

漏洞生命周期需要明确的状态门

可以这样实践：给 Agent 输出增加可执行验证门

接入现有研发流程时关注什么

相关推荐

建议反馈