AI代码审计最危险的不是漏报，而是团队开始不再相信它

AWS发布的Deception Benchmark是什么？它主要测试什么？

Deception Benchmark是AWS安全团队于2026年9月9日发布的一个基准，用于测试AI模型能否识别看起来危险但实际上已被有效缓解的代码。它包含14822个样本、16种语言和70多个CWE类别，评测了12个来自五家供应商的模型。挑战分为两类：代码级样本（危险版与已修复版只差一个细节）和环境门控样本（代码相同，但通过Kubernetes网络策略或身份权限阻断利用路径）。

为什么现有的安全评测基准不足以评估AI代码审计工具？

许多安全基准关注模型能否找到或利用漏洞，成功有清晰信号（攻击生效或失败）。但判断安全更难，因为不存在一个简单按钮证明所有攻击都不可能。参数化SQL、网络隔离、权限边界或输入净化都可能让可疑代码变得不可利用。现有评测无法衡量模型在识别已缓解代码时的误报和漏报权衡。

Deception Benchmark的官方结果显示了AI模型在误报和漏报之间怎样的权衡？

官方结果显示，标准单轮提示下精确率集中在约五成区间；受测通用模型没有一种配置同时把假阳性率与假阴性率控制在10%以内。要求模型提供利用证明能明显减少误报，却会漏掉更多真实漏洞。这揭示了精确率与召回率之间的现实权衡。

团队在验收安全AI工具时应该问供应商哪些问题？

安全负责人不应只问供应商能发现多少漏洞，还应问：在安全样本上会报多少、能否说明缓解措施、环境策略是否进入推理、结论如何复现。对于高风险路径，AI可以排序与收集证据，最终判断仍要结合静态分析、动态测试和人工审查。

如何根据资产等级设置不同的安全AI阈值？

团队可按资产等级设置不同阈值：互联网入口偏向高召回，内部低风险工具偏向高精确率；不要用一个总准确率掩盖两种错误的非对称后果。指标也要与处置成本绑定，例如一次低危误报可能只花五分钟，一次支付链路的漏报却可能造成重大损失。

团队如何在一周内构建一个小型欺骗集来评估安全AI工具？

团队可在一周内做一个小型欺骗集：1. 从过去三个月误报中选20例，并为每例记录有效缓解。2. 为每个安全样本制作一个仅去掉缓解措施的危险孪生版本。3. 让工具输出风险、可利用步骤、依赖环境与置信度。4. 分别统计误报率、漏报率、复现成功率和人工处理分钟数。5. 高危结论必须由第二种分析方法或人工复现确认。6. 每次模型、提示词或扫描规则升级后重复同一组回归测试。

Deception Benchmark有哪些使用边界和注意事项？

官方测试的是通用模型的单轮基线，不能直接代表带工具、多轮验证的完整产品。AWS认为额外脚手架未必能弥补基础理解缺口，但这仍需各产品在同一数据上证明。标签没有公开，9695条用于计分，其余5127条作为混入的未计分留出项，这有助于减少针对答案过拟合，却也要求依赖官方提交服务验证结果。不适合把这个基准单独当采购排名，也不应把未发现漏洞解释为系统安全。