AI 可以快速找出代码中“看起来危险”的模式，但发现疑点并不等于确认漏洞。缺少可达性分析、运行时验证和稳定复现时，扫描结果很容易被误报与模型幻觉淹没。Google 开源的 Mantis 试图把 AI 从单纯的告警生成器变成执行漏洞生命周期的智能体框架，覆盖识别、验证、复现和修复。
关键变化：扫描结果不再是终点
传统扫描流程通常停在静态告警：某个输入可能未过滤、某个依赖版本可能受影响，或者某条调用链可能触发危险操作。工程团队仍要手动回答几个决定告警价值的问题：
- 外部输入能否真正到达危险位置？
- 触发漏洞需要哪些配置、权限和运行条件？
- 能否构造稳定、可重复的测试用例？
- 修复后，原有功能和漏洞回归测试是否同时通过？
Mantis 所代表的方向，是让智能体继续推进这些步骤，而不是在生成一段漏洞描述后停止。一个候选问题只有经过验证和复现，才应该获得较高优先级；修复建议也应通过测试，而不是只依赖语言模型对代码的判断。
这种闭环尤其适合减少两类噪声：一类是语法模式匹配正确、但在当前程序中不可达的告警；另一类是模型给出了听起来合理、实际上无法触发的“漏洞”。
Agentic Harness 应该约束什么
“Harness”可以理解为智能体执行安全任务时的受控环境。它的价值不只是调用模型，还要约束工具、输入、输出和判定条件。
一条可审计的验证链通常需要保存：候选漏洞及对应代码位置、智能体提出的触发假设、实际执行的复现命令、标准输出和错误输出、退出状态、补丁内容，以及补丁前后的测试结果。
判定规则也应尽量由机器执行。例如，“复现测试在旧版本失败、应用补丁后通过”比“模型认为问题已经修复”更可靠。对命令执行、网络访问和文件写入还应设置沙箱、超时与权限边界，避免验证漏洞的过程本身影响开发机或生产环境。
需要注意的是，开源框架并不自动保证零误报。漏洞是否成立仍可能依赖业务语义、部署配置和外部系统。智能体适合收集证据和自动处理重复工作，高风险结论仍需要安全工程师确认。
可以这样实践：给候选漏洞增加可执行验证门
下面是一个与具体框架无关的最小示例，用来演示“候选发现必须通过复现命令才能升级”的机制。它不是 Mantis 的官方接口，而是可以接入类似智能体工作流的本地验证器。
先创建 findings.json：
[
{
"id": "SQLI-001",
"summary": "User input may reach a SQL query",
"repro_command": ["python", "-c", "assert 'admin' in 'admin OR 1=1'"]
},
{
"id": "PATH-002",
"summary": "Suspected path traversal",
"repro_command": ["python", "-c", "raise SystemExit(1)"]
}
]
再创建 validate_findings.py：
import json
import subprocess
from pathlib import Path
ALLOWED_EXECUTABLES = {"python", "python3", "pytest"}
TIMEOUT_SECONDS = 10
def validate(finding: dict) -> dict:
command = finding["repro_command"]
if not command or command[0] not in ALLOWED_EXECUTABLES:
return {**finding, "status": "blocked", "evidence": "command not allowed"}
try:
result = subprocess.run(
command,
capture_output=True,
text=True,
timeout=TIMEOUT_SECONDS,
check=False,
)
except subprocess.TimeoutExpired:
return {**finding, "status": "inconclusive", "evidence": "timeout"}
return {
**finding,
"status": "validated" if result.returncode == 0 else "rejected",
"evidence": {
"exit_code": result.returncode,
"stdout": result.stdout[-2000:],
"stderr": result.stderr[-2000:],
},
}
findings = json.loads(Path("findings.json").read_text(encoding="utf-8"))
results = [validate(item) for item in findings]
Path("validation-results.json").write_text(
json.dumps(results, indent=2, ensure_ascii=False),
encoding="utf-8",
)
for result in results:
print(f'{result["id"]}: {result["status"]}')
运行：
python validate_findings.py
cat validation-results.json
示例中，第一个候选项会被标记为 validated，第二个会被标记为 rejected。在真实项目中，应把 repro_command 替换成隔离容器内的单元测试、集成测试或专用漏洞复现脚本，并让智能体生成测试输入而不是任意 shell 字符串。
更完整的流水线还可以规定以下状态转换：
candidate -> validated -> reproduced -> patched -> regression-tested
-> rejected
-> inconclusive -> human-review
状态机能防止“发现”和“确认”混为一谈，也方便 CI、安全平台和人工审核共同消费结果。
接入现有研发流程时的边界
采用此类框架时，建议先从历史误报较多、又容易构造自动化测试的一类漏洞开始，例如输入校验缺失或路径处理问题。用已确认的真阳性和误报样本建立评估集，再比较引入智能体验证前后的准确率、平均验证时间与计算成本。
上线前至少检查这些事项：
- 所有智能体命令均在一次性容器或等价沙箱中执行。
- 默认禁用生产凭据、内网访问和不必要的外部网络访问。
- 每个结论都保留代码位置、复现步骤、日志和测试结果。
- 自动生成的补丁必须通过原有测试与新增安全回归测试。
- 高危漏洞、依赖业务语义的判断和大范围补丁必须经过人工审核。
- 对模型调用次数、执行时间和失败重试设置预算。
Mantis 值得关注的核心不是“再用一个模型扫描代码”，而是把漏洞工作组织成可执行、可验证、可回溯的闭环。真正降低误报的不是更自信的文字说明，而是可重复的证据和明确的质量门。