安全 AI 的能力与落地评测
一个代码审计助手能解释大量漏洞原理，也能对每次提交生成完整报告。但如果报告中的调用链无法复现，误报需要专家逐条排除，修复建议还会引入新问题，知识题得分再高也不足以支持上线。
安全 AI 的评测要证明它能在授权边界内完成安全任务，并且扣除复核、纠错和维护成本后仍有价值。 这里的“安全 AI”指用于安全分析、代码审计、漏洞挖掘、告警研判和授权攻防的模型或 Agent，不代表模型自身已经安全。
本文负责能力与落地效果。系统是否会被提示注入、越权或泄露，以及如何设计对抗样本、统计区间和发布证据，统一引用AI 系统安全评测与红队。两类评测需要共享版本与证据，但不能混成一个可相互抵消的总分。
能力面评测
先按任务建立能力分布，不急着给“最好的安全模型”排总榜。知识助手、审计助手和渗透 Agent 的输入、工具、验证方法与成功条件不同。
基础安全知识评测
检查漏洞类型、CVE/CWE 概念、Web、主机、云安全、密码学基础、安全开发、应急响应和攻击技术的理解。记录准确率、概念混淆、事实错误与来源有效性。
这一层适合发现基础缺口，不能直接证明任务执行能力。要求模型解释 SQL 注入，与要求它在给定仓库中找到真实可达的注入路径，是不同的测试。
安全分析能力评测
给模型真实但经过授权与脱敏的安全材料：WAF 告警、访问日志、漏洞报告、配置、威胁情报、代码片段或事件时间线。要求输出结论、支持该结论的原始证据、缺失信息和下一步验证动作。
例如，告警研判不能只看“判断为攻击”是否与标签一致，还要检查请求、时间、账号和资产的关联是否正确，有没有把正常业务异常当作攻击成功。按告警类型分别统计精确率、召回率、根因定位和证据引用正确性。
解释写得完整，与证据足以支持结论，需要分别判定。模型正确识别攻击类型却编造了一段日志，不应被算作合格分析。
漏洞发现与代码审计评测
评测对象包括源码、PR Diff、依赖升级、配置、IaC、补丁与漏洞可达性。任务至少说明代码版本、入口范围、部署条件、允许使用的工具和判定标准。
一个有效发现应能回答：入口在哪里，输入是否可控，经过哪些调用和检查，敏感操作是否可达，触发需要哪些条件，现实影响是什么。对修复建议，还要验证漏洞是否消失、正常功能是否保持。
不要只累计报告条目。相同根因在多个函数或多个请求上出现，应按预先约定的去重单位计数。已修复版本、不可达路径、有补偿控制的配置和无漏洞代码都要进入负样本集，否则很难衡量误报成本。
AI 漏洞挖掘提供问题选择与调查切口；本页只负责定义什么算有效发现，以及如何比较不同实现。
攻防任务能力评测
把授权目标、初始账号与权限、可访问资产、允许工具、查询预算和停止条件一起交给 Agent，在隔离环境中评估信息收集、路径推理、风险验证与报告交付。
成功必须由环境中的权威状态或独立验证器确认，不由 Agent 自述决定。HTTP 200 不自动等于绕过成功，报告“已获取权限”也不能代替可复核的权限证据。
同时记录任务完成率、有效验证率、攻击链证据完整度、消耗预算、人工介入与越界尝试。靶场任务和真实业务任务分开报告，不把边界明确的靶场结果直接外推到开放业务环境。可参考 CyberSecEval 3对不同网络操作评测对象的区分，具体企业结论仍需自己的任务与证据。
工程可靠性：同一任务能否稳定完成
模型能力需要由运行系统承接。冻结模型、Prompt、知识快照、工具、权限和运行时后，检查工具超时、限流、登录失效、部分结果缺失、上下文截断、重试与中途恢复。
一次正常调用成功，不能证明失败恢复正确。至少验证：失败是否被识别，已完成步骤是否重复产生副作用，状态是否保留，预算是否生效，是否能停止或移交人工，以及关键证据是否在恢复后仍可追溯。
重复运行要使用一致的预算，报告完成率与成本、时延的分布，不只展示最好的一次。模型、工具或提示变化后重新执行相同用例；不能同时改变系统版本、任务难度和预算，再把分数差异全部归因于模型。
风险面评测
安全风险是独立的准入约束。沿用系统安全评测与红队中的 Target Bundle、攻击者模型、Oracle 与分层指标，在安全任务环境中重点检查：
- 目标网页、代码注释、README、日志、工单或工具输出中的不可信内容，能否改变授权范围。
- 凭证、客户数据、源码和测试结果，是否可能流向未经批准的接收方。
- 高影响工具是否绕过参数绑定审批，重试是否扩大副作用，停止后是否仍有队列继续执行。
- 模型是否编造关键证据，并被下游系统或人工当作事实使用。
出现已验证的越权、敏感信息外发或破坏性副作用，不能靠更高漏洞发现率抵消。另一方面，模型提出危险动作但外部控制已经可靠阻断，与危险动作真正执行，也要分别记录，不能只凭“越狱成功”这个标签决定所有场景的发布结论。
安全控制实现见 Agent 与工具调用安全，责任与剩余风险接受见 AI 风险治理。本页不再重复维护通用攻击分类与治理规则。
业务面评测
最终要比较同类任务在不用 AI、使用现有工具和使用候选 AI 系统时的结果。基线、输入难度、人员经验与验收要求需要可比；无法同时控制时，应明确哪些差异仍可能影响结论。
按场景衡量效果：审计看确认的有效漏洞及其复核成本，告警研判看质量与处置时延，安全评审看端到端耗时与遗漏，应急响应看证据整理和处置建议是否可用。
将模型和工具费用、人工复核、误报处置、返工及持续维护纳入成本。生成报告更快，但让业务团队多花时间验证和修复，并不自动构成组织提效。
可使用一张分层结果表，而不是只有总分：
| 结果 | 口径 | 需要同时报告的限制 |
|---|---|---|
| 发现精确率 | 确认有效且去重的发现 / 提交复核的去重发现 | 复核范围、未决项和去重规则 |
| 漏洞召回率 | 找到的已知真实漏洞 / 评测范围内的全部已知真实漏洞 | 只适用于真值明确的评测集，未知漏洞无法直接成为分母 |
| 任务完成率 | 满足预定义验收条件的任务 / 全部评测任务 | 难度分层、预算、重复次数和失败原因 |
| 单位有效结果成本 | 模型、工具、人工复核和返工总成本 / 已验收结果数 | 结果定义、时间窗口；结果为零时单独报告，不能隐藏 |
| 端到端耗时 | 从任务接收到结果验收的时长 | 包含等待、复核与返工，并报告分布 |
| 人工接管率 | 需要人工接管的任务 / 全部任务 | 区分预期审批、信息不足和运行故障 |
推荐评测权重
不为所有安全 AI 预设一套通用权重。首先检查独立安全门禁；通过后，再按实际任务比较质量、覆盖、成本与时延。
确需综合评分时，应公开任务分布、归一化方法、权重来源和敏感性分析，并保留各分项结果。权重是组织的取舍，不是模型的客观属性；不能让知识问答分数掩盖审计误报，也不能让业务收益覆盖安全红线。
评测集设计
基础与任务样本。 公开基准用于对照，经过授权的内部历史漏洞、告警、评审、PR Diff、工单与应急事件用于贴近真实任务。两者分开报告，注明版本与来源。
负样本。 包括无漏洞代码、已修复漏洞、不可达路径、正常流量与误报告警。每个负样本也要有可复核的判定依据，不把“暂时没发现”自动标成绝对安全。
对抗与失效样本。 覆盖不可信输入、工具误用、权限受限、网络失败、上下文缺失与重试；评测结果分别归到系统风险和工程可靠性。
可重置交互环境。 为代码仓库、Web/API、日志查询、工单与模拟工具保存初始化状态、版本和重置过程。评测不得使用生产凭证或触发真实资金、邮件和删除动作。
业务样本。 根据实际服务的业务补充角色、权限、状态机与数据规则，避免用通用靶场完全替代业务逻辑评测。
同一 CVE、同一根因、同一项目的近似版本应尽量按组切分训练、调参和保留测试集。明确区分已知漏洞复现、补丁辅助发现与未知缺陷调查；不能把看过补丁后的复现成果当作无先验发现能力。
评测流程
先定义任务与成功条件，再确定范围和风险等级。建立样本及基线后冻结系统版本，自动执行并保留输入、工具调用、判定结果和成本；由专家复核高影响、争议、误报、漏报与一部分判正常样本。
报告将能力、工程、风险和业务四部分分开。安全门禁通过后，只在批准范围内灰度试用；线上反馈经过脱敏与复核进入回归集。具体的系统版本绑定、统计区间与 Judge 校准复用系统安全评测方法，运行监控与停止流程复用运行监控与事件响应。
门禁分级
可以用 P0—P3 管理问题，但它们是企业内部的处理优先级示例，不是按某种攻击名称自动映射的行业标准。
P0：禁止按当前能力发布。 已验证的未授权访问、敏感信息外发、审批绕过后的高影响动作、破坏性副作用或关键证据造假，都需要停止对应能力并修复验证。
P1：仅在明确降级后发布。 问题仍存在，但通过关闭工具、缩小数据与资产范围、改为只读或强制人工验收，能够证明危险路径已被阻断。降级本身要测试，不能只写在例外说明中。
P2：质量缺口。 表达、非关键解释或低影响误报等问题可以进入改进计划，但必须统计实际复核负担。若质量错误会驱动自动封禁、生产修复或其他高影响动作，应重新评定后果。
P3：探索问题。 未覆盖任务与研究假设明确标注为未验证，不阻断当前已限定用途，也不能被宣传成已经具备的能力。
建设路径
最小版本可以选择一个真实任务：准备代表性正负样本、明确授权范围、保存可复核证据，建立不用 AI 的基线，再加入运行故障和对抗输入。先证明这个任务的质量、控制与成本，再扩展任务范围。
成熟阶段逐步沉淀私有任务库、业务逻辑样本、可重置 Agent 环境、独立验证器、线上灰度与持续回归。系统架构可结合AI 自动化渗透，通用评测编排可参考 Inspect AI，但环境和工具不能替代任务真值。
安全 AI 值得上线的证据，是它在明确边界内持续交付了可信结果，并减少了真实工作负担。知识分数、报告数量和一次演示都只是其中一部分材料。