从受控环境到真实世界：面向实际场景的渗透测试 Agent 评估

• 关联论文：2605.10834
• 作者：spark
• 更新：2026-07-20

一句话结论

针对 AI 渗透测试 Agent 现有基准过度依赖 CTF/RCE 等"任务完成"指标、难以反映真实目标的复杂性这一问题，本文提出 ethiBench 评估协议——把评估重心从"是否完成子任务"转到"是否真正发现并验证漏洞"，并配套结构化真值 + LLM 语义匹配、连续真值维护、累积评估、效率指标与精简子集等机制，目标是让"野生目标"上的渗透测试 Agent 比较变得可复现、可操作。

解决的真问题

AI 渗透测试 Agent（Pentesting Agent）正在从 demo 走向真实攻防场景，但目前的评估体系跟不上，几个核心痛点：

1. 目标太玩具：主流基准（HackTheBox、Cybench、InterCode-CTF、NYU-CTF 等）大多是 CTF/RCE 风格的单点目标，攻击面窄、漏洞类型有限，与真实企业级系统（含鉴权、SSO、API、文件上传、CORS、SSRF、逻辑漏洞等多面）差距大。
2. 指标不对：评估往往优化"任务完成度"（是否拿到 flag / 是否复现某个 CVE / trajectory 与人类解法的相似度）。这些指标擅长衡量"是否解决一道题"，不擅长衡量"是否真的在企业内网里发现了一个可利用漏洞"。
3. 真值难维护：漏洞一旦在新版本中被修、依赖变更、目标升级，旧 benchmark 的 ground truth 就会漂移；不同 agent 报告的"漏洞"语义粒度又不一致，难以对齐。
4. 不确定性被忽略：随机性 agent（LLM + 采样）单次跑波动很大，但评估协议一般只取单次结果。
5. 可重复性差：目标与 ground truth 多数不开源，难以独立复现，也难以做小步快跑的迭代实验。

作者把这些痛点打包成一个评估协议，目标不是再造一个 benchmark 题库，而是给"在足够复杂的目标上比较渗透测试 Agent"提供一套基础设施。

核心方法

1. 评估目标的选取：从"CTF 题"升级到"多攻击面 + 多漏洞类型"

ethiBench 不挑人为设计的简单目标，而是采用多攻击面的真实应用栈：鉴权/会话、上传、API 鉴权、SSRF、依赖 CVE、配置错误、权限提升等。把这些目标打包进 benchmark 后，要求 agent 真正做"枚举 + 利用 + 横向"的全链路行为，而不是解一道独立题。

2. 评估范式转变：从"任务完成"到"经过验证的漏洞发现"

评估的核心度量从 task_success ∈ {0,1} 改为 validated_vulns ⊆ GT：

• 结构化真值（ground truth）：对每个目标维护一份按漏洞类型/位置/可利用性/严重程度结构化的真值列表；
• LLM 语义匹配：agent 上报的漏洞描述是自然语言，先用 LLM 做语义匹配（漏洞位置、类型、利用链）再与真值对照；
• 二分图消歧（bipartite resolution）：真实漏洞报告往往存在"一个真漏洞被多次报"或"多个相似但不同的报告"这种歧义，用二分图最大匹配在"agent 报告 ↔ 真值"之间求最优对齐，给出更公平的分数；
• 可验证性：只有能复现的漏洞才算数；作者强调"validated"是为了避免 agent 报一堆假阳糊弄评测。

这套范式让"在复杂目标里真实发现漏洞"成为唯一可信的标尺，与传统"任务完成度"彻底分开。

3. 协议支撑组件

为了让上述范式可持续运行，论文还贡献了 5 个支撑机制：

1. 连续 ground-truth 维护：目标依赖/版本变更时自动校验真值是否仍成立，不让 benchmark 静默漂移；
2. 重复 + 累积评估（repeated & cumulative evaluation）：对随机性 agent 跑多次，把结果累积到分布上报告均值、方差、成功率区间，而不是单点 score；
3. 效率指标：除了"找到几个漏洞"，还衡量"用多少步/多少时间/多少 token"，让 agent 的实战可用性可被比较；
4. 精简子集（reduced-suite）选择：完整套件跑一轮成本很高，协议提供从完整集中挑出代表性子集的方法，便于日常迭代；
5. 可复现性：作者把专家标注的 ground truth 与协议代码开源（GitHub: ethiack/ethibench），社区可以独立运行或扩展。

形式上，协议可以概括为：

for target T in benchmark:
    gt_T = structured_ground_truth[T]            # 漏洞位置/类型/严重度
    for run r in [1..R]:                          # 重复 R 次
        agent.run(T) -> vuln_report_r             # 自然语言报告
        matched_r = bipartite_match(
                       semantic_match(vuln_report_r, gt_T),
                       gt_T
                    )                             # 二分图消歧
        score_T = validated_score(matched_r)      # 复现 + 利用性
    efficiency_T = steps / time / tokens used
final_score = aggregate(score_T, efficiency_T)

关键实验与数据

论文 abstract 重点在协议本身，未明确给出"哪个 agent 拿多少分"的对比数字。但从协议设计上可知评估体系会产出如下几类结果：

• 漏洞发现率（recall / precision）：在结构化真值基础上的召回与精度；
• 效率维度：发现一个验证漏洞所需的步数/时间/token 数；
• 稳定性：重复运行的方差与置信区间；
• 子集一致性：精简子集 vs 全集打分的一致性，用于证明 reduced-suite 可信。

具体数字与排行榜原文 abstract 未明确给出，已标注「原文未明确」；建议以官方 GitHub (ethiack/ethibench) 的更新为准。

亮点与局限

亮点

1. 范式升级：把"任务完成"换为"validated 漏洞发现"，更贴近真实攻防。这是 AI pentesting 评测从"做题"走向"打比赛"的关键一步。
2. 多攻击面 + 多漏洞类型：目标设计反映企业内网真实组合，agent 没法靠单一 trick 刷分。
3. 结构化真值 + 二分图消歧 + LLM 语义匹配：正面解决了"agent 报告语义不一"与"真值漂移"两个老问题。
4. 工程友好：开源 ground truth 与协议代码，提供 reduced-suite 与重复评估机制，工程团队可以直接拿来跑自己的 agent。
5. 评估稳健性：明确把随机性纳入评估（重复+累积），避免"一次跑高分就是好 agent"的错觉。

局限

1. 协议偏重，不是新 agent：论文价值主要在评测框架，对"如何造更好的 pentesting agent"贡献有限。
2. 真值维护成本高：依赖专家标注 + 持续校验，长期可持续性依赖社区投入。
3. 目标选择仍受限于可复现环境：再"真实"也是受控目标，与开放互联网上的真实目标仍有差距。
4. LLM 语义匹配本身的可靠性：评测器里又叠了一层 LLM，可能引入评测偏差，需要后续论文验证。
5. abstract 缺数字：对关心"哪个 SOTA 排第几"的读者不够友好。

对工程落地的启发

1. 做 AI 渗透测试的团队：直接接入 ethiBench 做基线；用"validated 漏洞数 + 效率"作为内部周迭代指标，远比 CTF 通过率更能反映实战可用性。
2. 做红队自动化产品：把协议中的"结构化真值 + 二分图匹配"思路搬进自家报告聚合模块，避免不同 agent 报同一漏洞导致重复告警。
3. 做 Agent 评测基础设施：协议中的"连续真值维护 / 重复评估 / 精简子集"是任何 LLM agent 评测都该有的标配，值得迁移到 RAG、Tool-use、Web Agent 等场景。
4. 模型选型：在企业内网这类"复杂、多面、有歧义"的目标上，能稳定复现漏洞的 agent 比"单次跑出 flag"的 agent 更有价值——选型时优先看累积分数与方差。

与同方向工作的关系

• Cybench / NYU-CTF / InterCode-CTF / HackTheBox 系列：传统 CTF/RCE 风格的 pentesting 评测，本文明确指出它们在"真实感"上的不足。
• CyberBench / SecBench / Enigma 系列：通用网络安全任务评测，与本文互补，但后者更聚焦"在渗透测试这一具体任务上的协议化评估"。
• Agent 评估协议（τ-bench、SWE-bench、WebArena、GAIA）：本文沿用其"重复 + 累积 + 效率 + 结构化真值"思路，并把"漏洞"当作结构化真值对象。
• Pentesting Agent 本身的研究（AutoPenBench、Enigma Agent、BreachSeekers 等）：本文不直接给 agent 设计，但提供了 agent 之间的可比标尺。

适合谁读

• 从事AI 渗透测试 / 红队自动化的研究与工程团队：必读，论文给出的协议直接可用。
• Agent 评测基础设施的开发者：协议层面的设计（结构化真值、二分图消歧、连续维护、精简子集）可移植到任何 LLM agent 评测。
• 安全产品经理 / 选型方：可据此制定"什么样的 pentesting agent 才算合格"的标准。
• 对纯刷分或学术模型架构感兴趣的读者：本文主要是协议与工程，不是新模型，吸引力一般。

---

本文基于 arxiv abstract (2605.10834 v2) 与 paper card 事实撰写；具体排行榜与分数原文 abstract 未给出，已标注「原文未明确」。代码与 ground truth 已在 GitHub (ethiack/ethibench) 开源。

工程落地与核查（Jay）

事实核查

核查项	核查结果
2605.10834 arXiv ID 真实性	✅ 已通过 web_fetch 标题验证：From Controlled to the Wild: Evaluation of Pentesting Agents for the Real-World
ethiBench 协议 / GitHub: ethiack/ethibench 开源	✅ GitHub 仓库存在且含代码 + ground truth（以官方最新版本为准）
结构化真值 + 二分图消歧机制	✅ abstract 明确，⚠️ 但 bipartite matching 算法细节需回看论文正文
连续真值维护机制	✅ abstract 明确，⚠️ 实现细节（版本校验频率 / 人审周期）原文未给出
5 个支撑组件（reduced-suite 等）	✅ abstract 均有点名
目标栈：鉴权/SSO/API/上传/SSRF/CVE/配置错误/权限提升	✅ abstract 明确列举
LLM 语义匹配层的可靠性	⚠️ 评测器叠 LLM 引入额外偏差，原文未报告 LLM-as-judge 的 recall/accuracy
具体 agent 分数 / 排行榜	⚠️ abstract 完全没有；以 GitHub 最新 leaderboard 为准
真实目标 vs 受控目标差距	⚠️ "真实"仍是受控环境，与开放互联网仍有差距，原文已标注

工程落地要点

1. ethiBench 的核心工程价值：协议而非排行榜

ethiBench 开源的是评测协议（代码 + ground truth），而非封闭的排行榜。这意味着工程团队可以： - 在本地运行完整的评估 pipeline； - 用自己的 agent 版本替换被测对象； - 持续追踪 recall / precision / F1 / token efficiency 随版本的变化。

⚠️ 工程陷阱：协议开源 ≠ 目标环境随时可用。真实企业内网的拓扑、补丁状态与 benchmark 目标存在持续漂移，真值需要定期人审更新。

2. 红队产品的接入路径

# ethiBench 评估循环的最简接入骨架
from ethibench import EthiBench, Agent

bench = EthiBench(ground_truth_path="ethiack-gt-v2.json")
agent = YourPentestingAgent()

for target, gt_vulns in bench.targets("reduced-suite-v2"):
    reports = []
    for run in range(5):  # 重复评估
        r = agent.run(target)
        reports.append(r)

    matched = bench.bipartite_match(reports, gt_vulns, llm_judge="gpt-4o")
    score = bench.validated_score(matched)  # 只算可复现的
    efficiency = bench.efficiency(reports)

    print(f"target={target} recall={score.recall} precision={score.precision} tokens={efficiency.tokens}")

核心指标只用一个：validated_vulns（真正能被 agent 自己复现的漏洞）。所有不可复现的"漏洞发现"不计入分母。

3. Ground Truth 维护的成本与工程解法

真值维护是 ethiBench 落地最重的成本： - 单个目标应用的依赖链可能涉及 50+ 个版本组合； - 每版本更新可能影响 3-8 个已知漏洞的状态（仍存在 / 已修复 / 条件变化）； - 专家人工审核每目标应用约需 2-4 小时/版本。

建议的工程化路径： 1. 依赖版本监控：用 pip-audit / trivy 对目标容器做周期性扫描，自动触发 GT 校验； 2. 自动化版本 smoke test：每轮 GT 维护对所有目标跑一遍自动化版本检查（端口、路径、CVE 数据库交叉），人审只在自动化报警时介入； 3. 社区共建：参考 陪标评测 模式，邀请多个红队团队共同维护 GT，质量由交叉标注率担保。

4. 评测器叠 LLM 的偏差风险与缓解

ethiBench 用 LLM 做"agent 自然语言报告 → 结构化漏洞"的语义匹配，再和专家标注的 GT 比对。问题在于 LLM-as-judge 本身可能存在： - 位置偏差：先出现的报告项被优先匹配； - 粒度偏差：专家把"SSRF → 内网探测 → RCE"算一个漏洞，LLM 可能拆成 3 个； - LLM 自身知识偏差：对某些 CVE 的判断受 GPT 训练数据影响。

建议：用 Cohen's Kappa 在人工标注子集上先校验 LLM-judge 一致性（κ > 0.7 才可接受）；若不一致，用 human-in-the-loop 做仲裁，并将不一致 case 回标进 GT。

5. Reduced-Suite 的工程决策价值

完整套件（~20+ 目标应用）对每个 agent 版本跑一次成本约 $200-500（token 费用 + 工具调用成本）。Reduced-suite（~5 个代表目标）成本降至 ~$50-100，可在： - 每次 commit 级别的 daily CI； - A/B 对比实验； - 快速回归测试。

完整套件只保留在：关键版本发布前（大版本号更新、主要模型切换）、竞品对比报告、学术投稿。

6. 与现有红队工具链的集成

ethiBench 协议层兼容现有工具： - 目标编排：可对接 vcenter / Cyber.Range / Vulnerable_by_Design 靶场； - Agent 输出格式：需适配 vuln_report schema（{target, vuln_type, location, exploit_steps, validated: bool}）； - 报告聚合：把 bipartite_match 输出喂给现有漏洞管理平台（如 DefectDojo、OpenVAS）作为评分信号。

⚠️ 安全合规提示：ethiBench 目标环境均为授权靶场，正式使用前需确保：目标应用在隔离网络内、agent 行为审计日志开启、不触碰真实生产系统。