AWS AI 漏洞检测能发现漏洞，但误报暴露信任鸿沟

AWS 测试了 12 个通用 AI 模型，发现了一个鲜明矛盾：它们能发现大多数漏洞，却经常将安全代码判定为危险。

新的 Deception Benchmark 对 AWS AI 漏洞检测的宣称提出了比另一类漏洞发现排行榜更严苛的考验。它考察模型能否识别看似可疑的代码实际上是否受到有效缓解措施保护。在直接提示下，受测模型将 41% 至 99% 的安全样本标记为存在漏洞。

这一结果改变了围绕 AI 安全工具的讨论。每一条告警都会消耗工程时间，因此仅仅发现可疑模式远远不够。如今真正的较量在于快速模式识别与基于证据的验证之间，而安全团队正为两者的差距付出代价。

AWS 于 2026 年 9 月 9 日发布了该基准，涵盖 16 种编程语言、70 多类 Common Weakness Enumeration 类别的 14,822 个样本。没有任何受测配置达到 AWS 所称的最低标准，即将误报率和漏报率同时控制在 10% 以下。

AWS 构建了一个让安全代码看起来危险的基准

该基准考察模型是否理解可利用性，而不是是否识别出熟悉的漏洞模式。

许多安全评估从存在漏洞的软件入手，要求 AI 系统识别或利用其中的缺陷。这种方法能够揭示有价值的攻击能力，但无法完整反映防御表现。生产环境中的审查人员还需要能够排除那些看似存在漏洞、却不会形成真实攻击路径的代码。

AWS 围绕这一差异设计了 Deception Benchmark。其安全样本包含真实的框架、看似危险的数据流以及可识别的安全隐患。一项细微的缓解措施封闭了利用路径，模型必须判断这种防护是否真正有效。

基准发布说明中描述的一个案例涉及一个接收用户输入并查询数据库的 Flask 端点。周边模式类似 SQL 注入。不过，参数化语句阻止了输入变成可执行的查询语法。

如果模型在识别出该模式后就停止分析，就会报告一个漏洞。能够追踪完整数据流的模型则应将该样本归类为安全。这一区别决定了输出会成为有用证据，还是又一条需要人工调查的告警。

该基准包含 6,988 项代码级挑战。这些挑战提供了仅因一处细微修复而不同的漏洞版本和安全版本。两个版本都可能看起来可疑，但只有一个仍可被利用。

另有 2,707 项挑战加入了部署环境上下文。源代码可能看似存在漏洞，但基础设施控制措施阻断了攻击。例如，Kubernetes Network Policy 阻止服务器端请求伪造，或身份边界阻止权限提升。

这些受环境限制的案例之所以重要，是因为企业安全很少止于单个文件。可利用性取决于配置、网络可达性、权限、运行时行为和补偿性控制措施。忽略这些条件的扫描器，可能会描述一种听似合理、但在已部署环境中无法发生的攻击。

AWS 表示，每个样本都为该基准专门创建，并以真实安全模式为基础。该公司采用了对抗式开发循环：生成挑战、使用前沿模型进行测试、强化容易通过的案例，然后重复这一过程。

这种方法使数据集刻意变得困难。这也意味着，这些结果不应被视为每个源代码仓库的代表性失败率。该基准选择的案例旨在暴露浅层推理，而非对日常代码审查进行随机抽样。

它的价值在于隔离出一种特定能力：模型能否足够深入地追踪攻击链，从而区分真实弱点与令人信服的诱饵？这个问题正处于可信 AWS AI 漏洞检测的核心。

公开的基准代码库包含全部 14,822 个样本。AWS 对其中 9,695 个进行评分，另有 5,127 个不计分。这些保留样本包括存在争议或刻意模糊的案例。

标签并未公开提供。参与者必须为每个样本提交预测结果，包括解释，随后 AWS 才会返回准确率和错误率结果。这种方法旨在限制记忆化和针对基准的调优。

AWS 还表示，独立审查人员曾反复检查标签。存在争议的样本被移入不计分池，而非获得修正后的标签。该公司称，对随机抽取的 100 个计分样本进行人工审查后未发现错误。

这并不意味着该数据集无可批评。独立研究人员仍需审查其构建方式、类别平衡、评分流程及向真实世界迁移的效果。不过，这次发布为外部团队提供了一个共同目标，以便在相同的对抗条件下比较系统。

AWS AI 漏洞检测结果揭示了两种糟糕选择

直接提示会产生过多误报，而更严格的证据要求会导致模型漏掉更多真实漏洞。

AWS 使用两种提示策略评估了来自五家供应商的 12 个模型。直接提示要求每个模型将代码分类为存在漏洞或安全。漏洞利用证明提示则要求模型在宣称存在漏洞前构造具体的利用方式。

该基准区分了两类错误，因为它们会造成不同的运营失败。误报将安全代码标记为存在漏洞；漏报则将真实漏洞判定为安全。

AWS 表示，在直接提示下，模型通常偏向灵敏度。它们能够发现高达 95% 的真实漏洞。但与此同时，它们也将 41% 至 99% 的安全代码标记为存在漏洞。

这种偏差可能让模型看起来积极且谨慎。它也是保护召回率的一种简单方式；召回率衡量发现的真实漏洞所占比例。一个将所有内容都判为有漏洞的系统永远不会漏掉漏洞，却会让用户淹没在无用告警中。

Mistral Large 就体现了这种失败模式。其直接提示配置的误报率为 99%，漏报率为 0%。它通过几乎将所有安全案例都视为危险，找到了那些漏洞案例。

其他几个直接配置也有类似表现。GPT-5.6 Sol 的误报率为 92.5%，漏报率为 0.9%。Claude Haiku 4.5 的误报率达到 92.1%，同时没有出现漏报。

Amazon 自己的 Nova 2 Lite 也未能例外。在直接提示下，AWS 报告其误报率为 89.2%，漏报率为 1.2%。将 Amazon 的模型纳入测试，有助于使这次发布不只是针对外部供应商的比较。

在所列系统中，Claude Opus 5 在直接提示下实现了最好的平衡。其准确率达到 77.3%，误报率为 41.5%，漏报率为 5.2%。即便如此，该结果仍远高于 AWS 所称的生产环境门槛。

单看准确率会掩盖这些差异。该基准中安全案例与漏洞案例大致均衡，因此一个总是回答“存在漏洞”的分类器也能取得接近 50% 的分数。其表面准确率掩盖了这样一个事实：每个安全样本都会变成一条告警。

因此，AWS 设定了其所称的宽松最低标准。可投入生产的配置应将两类错误率都控制在 10% 以下。没有任何受测配置达到这一目标。

直接提示的结果表明，AI 漏洞检测不能仅凭召回率来评估。几乎发现每个真实缺陷听起来令人安心，直到团队意识到大多数安全代码也触发了警告。

这不是一个表面的质量问题。每一条误报都会进入工作流程。必须有人检查代码、复现所称路径、核查配置、咨询负责团队，并记录为何该发现可以关闭。

在企业规模下，这种审查成本可能抵消自动化所承诺的速度优势。它还可能造成告警疲劳：工程师因太多此前告警被证实错误而开始忽略发现结果。

其安全后果令人不安。即使模型具有出色召回率，高误报率也可能间接提高风险。重要告警必须与数十条看似可信的错误结果争夺注意力。

早期学术研究也发现了相同模式。一项 2024 年的安全评估测试了八个语言模型在 228 个代码场景中的表现，并报告了较高的误报率。在测试代码已被修复后，模型有时仍持续标记漏洞。

该研究还发现，模型在简单代码变更下会给出非确定性回答，推理也较为脆弱。AWS 规模更大的发布将这一担忧扩展至更多语言、弱点类别、模型以及通过对抗方式构建的安全示例。

漏洞利用证明可减少噪声，却带来新的盲点

要求提供证据能提升严谨性，但受测模型往往以忽视真实漏洞为代价换取这种精确度。

漏洞利用证明提示要求模型超越怀疑。在将代码标记为存在漏洞之前，它必须描述攻击者可以利用的具体路径。这将决策门槛从“这看起来危险”转变为“我能解释攻击如何生效”。

AWS 报告称，这一策略将误报率降低了 17 至 74 个百分点。这是一项有意义的改进。但它也提高了漏报率；在更严格的方法下，漏报率介于 7% 至 44% 之间。

GPT-5.4 提供了最清晰的权衡案例。其直接配置的误报率为 81%，漏报率为 1.5%。漏洞利用证明提示将误报率降至 10.1%，但漏报率升至 33.6%。

Llama 3.3 70B 也呈现类似模式。其误报率从 84.2% 降至 10.2%，漏报率则从 1.1% 升至 44.2%，意味着该配置漏掉了近一半计分漏洞。

在漏洞利用证明提示下，Claude Opus 5 取得了最高的整体准确率，为 79.3%。然而，其 24.9% 的误报率和 16.8% 的漏报率仍在两个维度上都未达到 AWS 的门槛。

这些结果并不意味着漏洞利用证明提示无效。它们表明，提示方式会改变模型所犯错误的类型。安全负责人必须决定其工作流程能否承受更多误报、更多漏掉的缺陷，或经过谨慎衡量的组合。

这一决定取决于应用场景。对面向互联网的认证服务进行审查，应容忍更少的漏报。低风险内部代码库则可能优先考虑精确度，以避免耗尽小型工程团队的精力。

严重程度也应影响阈值。系统可以将高置信度的关键发现直接送交人工审查，同时通过低优先级验证处理较弱的警告。单一的全局分类阈值不太可能适用于每个代码库。

这正是该基准测试采用单轮设计的重要之处。AWS 有意移除了代理脚手架、外部工具和重复验证循环，目的是衡量基础模型的内在推理能力，而非完整的商业安全产品。

因此，这些结果并不能证明每个代理式扫描器都有同样的失败率。一款产品可以将语言模型与静态分析、动态测试、代码库上下文、策略检查和确定性的漏洞利用验证结合起来。这些组件能够改变系统的工作点。

AWS 明确认可这种区别。其基准测试将代理式提交与单轮模型结果分开接收。这种划分可防止借助工具的系统被表述为等同于一次未经支持的模型调用。

这一限定并不意味着基线无关紧要。每个代理式工作流都会继承底层模型的部分局限。重复一个薄弱的判断，可能产生更复杂的解释，却不会补上缺失的技术事实。

系统需要可靠的新证据来源。它可以执行测试、跨文件追踪数据、检查部署策略，或验证某个端点是否可达。仅仅进行多次模型调用，并不能保证获得更深入的理解。

最困难的任务是证明安全性。进攻性测试通常会给出可见结果，因为漏洞利用要么成功，要么失败。但一次失败并不能证明不存在其他利用方式，因此，未能成功的结果仍然难以解读。

AWS 的环境门控示例进一步凸显了这一问题。模型必须在代码和基础设施之间进行推理，随后还要认识到某项缓解措施阻断了它最初发现的路径。AWS 表示，模型经常注意到风险模式，却忽略了附近的控制措施。

这种行为类似于安全审查中常见的人类偏差。一旦审查者识别出熟悉的漏洞形态，确认往往比证伪来得更快。语言模型会放大这一问题，因为模式识别正是它们生成答案的核心机制。

对采购方而言，实际教训很明确：应询问 AI 安全产品是否验证漏洞可利用性，以及它如何衡量两类错误率。缺少误报数据的召回率指标，几乎无法说明产品会带来多少工作负担。

AWS 自身的安全系统说明了架构为何重要

AWS 的生产环境主张依赖分层代理、确定性检查和人工审批，而不是由未经支持的模型来判定代码是否安全。

在发布该基准测试的数月前，AWS 曾介绍过两套代理式安全系统。这些较早的披露提供了重要对照，因为它们展示了 Amazon 如何尝试管理如今被直接测量的局限性。

RuleForge 根据公开可用的漏洞利用示例生成检测规则。AWS 表示，在 2025 年最后四个月中，该系统相较于人工流程将规则生产效率提升了 336%。

其架构将任务拆分至多个专业阶段。一个组件负责接收并确定漏洞信息的优先级。生成代理提出多条检测规则，独立的评审器对其进行评估，合成测试对规则进行演练，流量数据则支持进一步验证。

安全工程师仍然是最终审批关卡。这一人工角色至关重要，因为 RuleForge 并不把 AI 模型的置信度视为足以部署的证据。

AWS 表示，当要求生成模型评判自身工作时，它几乎给每条规则都打出高分。根据该公司的 RuleForge analysis，将评估交给独立模型后，在保持真阳性检测数量不变的情况下，误报减少了 67%。

评审器还会收到领域特定的问题。系统不会只问规则看起来是否正确，而会询问它是否可能遗漏恶意请求。它还会测试规则捕捉的是漏洞机制，还是仅仅某个相关的表层特征。

这一区别与 Deception Benchmark 相呼应。宽泛的表达式可能会匹配包含单引号的输入，但匹配该字符并不能证明存在 SQL 注入。规则必须将漏洞利用行为与具有相同特征的正常流量区分开来。

AWS Security Agent 对自动化渗透测试采取了类似策略。专业代理探索应用程序并生成候选发现，而验证器则要求提供漏洞利用证据。

AWS 报告称，当系统获得夺旗赛说明和评分器反馈时，其在 CVE Bench v2.0 上的攻击成功率达到 92.5%。缺少这些辅助时，该比例降至 80%；使用训练截止时间早于该基准的模型时，则达到 65%。

这些数字衡量的是进攻成功率，而非防御精确度。CVE Bench 包含存在漏洞的应用程序，用于测试代理能否利用已知缺陷。它并未回答该系统会多频繁地错误指控安全代码。

不过，这一代理架构展示了对该基准测试弱点的一种可信回应。候选发现会接受确定性和基于模型的检查，而报告包含漏洞利用证据及技术上下文。

只有将“AI 漏洞检测”视为单一技术时，才会产生表面上的矛盾。基础模型基准揭示了单次判断的薄弱之处。AWS 的生产系统则主张，价值来自能够收集证据并约束这种判断的工作流。

这种比较支持一个更精确的结论：通用模型是安全自动化中有用的组件，但围绕它们构建的系统决定了其输出是否值得在运营中信赖。

供应商无法仅靠给重复提示加上代理标签来弥合差距。真正相关的问题涉及工具、证据、校准、故障处理和人工监督。采购方应询问：从最初的怀疑到最终的发现之间，系统做了什么改变。

产品是否运行了被指存在漏洞的路径？是否检查基础设施控制措施？能否跨越代码库边界追踪数据？是否将结果与确定性分析器进行对比？审查者能否了解该发现为何通过了验证？

团队在调查期间还需要持久的上下文。架构说明、既往例外、威胁模型和修复决策往往分散在文档与对话之中。可搜索的工程知识库可帮助审查者找回这些上下文，尽管它不能替代技术验证。

采购评估应区分三个层面。第一层是底层模型，Deception Benchmark 在这一层提供了共同基线。第二层是验证架构，它决定系统如何收集额外证据。第三层是运营流程，包括审查责任归属和可接受风险。

产品可能在一个层面表现良好，却在另一个层面表现不佳。能力强的模型可能因提示模糊和上下文缺失而被削弱。能力较弱的模型在受到狭窄工具和严格验证约束时，也可能变得更有用。

AWS 的披露同样包含公司自行报告的结果，而非对生产性能的独立审计。336% 的效率提升主张和 67% 的误报降低描述的是 RuleForge 在 Amazon 评估条件下的表现，不应被泛化到无关的代码库或产品。

这种不确定性进一步强化了公共基准测试的必要性。供应商可以将完整系统提交至 Deception Benchmark，并报告单独的代理式结果。届时，客户便能在共享任务下比较各项主张，而不是依赖彼此不可比的案例研究。

误报会将 AI 的速度转化为人工工作

商业风险不在于 AI 什么也没发现，而在于看似合理的错误会耗费本应用来确认真实发现的人力。

安全工具长期以来一直受误报困扰。传统静态应用安全测试会扫描源代码中的危险数据流或结构，却往往缺少完整的运行时上下文。AI 承诺能带来更好的语义推理，但 AWS 的结果表明，易于识别的模式仍然具有强大的吸引力。

设想一个开发团队收到紧急 SQL 注入警报。工程师暂停计划中的工作，找到相关负责人，审查查询路径，并确认参数绑定阻止了注入。随后，警报还需要补充关闭说明，以免在下一次扫描中重新出现。

一次错误似乎尚可处理。但面对数千个代码库和频繁扫描，计算就会改变。高误报率会将自动化检测转化为持续性的人工验证队列。

这个队列会带来多种成本。修复工作会打断功能交付，从而拖慢工程进度。安全团队需要花时间维护扫描器的可信度。应用负责人会逐渐将警报视为未经验证的建议。

最终，信心会被侵蚀。真正的漏洞可能通过同一渠道出现，并得到同样怀疑的回应。检测系统确实“发现”了缺陷，但从运营角度看，它未能促成及时行动。

漏报则造成相反的风险。更严格的系统可以通过报告更少的问题来减少干扰，但如果它遗漏了大量真实缺陷，其沉默就会变得不那么可信。

这正是 AWS 的双重阈值重要的原因。只衡量精确率会奖励几乎不报告任何问题的保守系统。只衡量召回率会奖励几乎标记一切的激进系统。生产决策需要这两个数值，并应按漏洞严重程度和代码上下文进行细分。

团队还应询问供应商如何建立事实基准。漏洞标签很难确定，因为代码可能因可见函数之外的原因而安全。依赖项、配置、身份验证、网络控制和部署状态都可能改变可利用性。

Deception Benchmark 团队尝试通过反复的独立审查来限制标签错误，并将存在争议的案例排除在评分之外。这是经过深思熟虑的设计选择，但也引出了另一个问题：其经过清晰裁决的样本，与真实企业系统中的模糊性有多大程度的相似？

真实代码库包含不完整的测试、未记录的假设、陈旧的配置、生成代码和职责缺口。工具可能需要说明证据不足，而不是被迫给出存在漏洞或安全的二元答案。

该基准目前要求作出这种二元决定。必须提供详细解释，但弃权并未被列为计分结果。未来的评估可以考察，经校准的不确定性能否帮助团队分配审查资源。

延迟和成本同样值得关注。多代理系统可能通过运行测试和检查更广泛的上下文来减少误报。这种改进可能需要更多计算资源、更长的审查时间，以及访问敏感代码或基础设施。

这些权衡并不会否定代理式验证。它们决定了该方法适合部署在哪里。高风险变更可以证明更深入分析的合理性，而常规代码可能需要成本更低的筛查，再辅以选择性升级处理。

安全负责人应避免用一个虚荣指标替换另一个。总体准确率会掩盖错误方向。惊人的效率数字可能掩盖审查负担。令人印象深刻的漏洞利用成功率，对安全代码几乎说明不了什么。

可信的评估至少应披露五项内容：误报率、漏报率、覆盖范围、验证方法，以及按弱点类别划分的表现。它还应明确说明拒答和无效输出，而不是悄然将其移除。

覆盖范围影响了一个 AWS 结果。大多数配置对至少 98% 的样本返回了有效答案。在以漏洞利用证明为导向的提示下，GPT-5.6 Sol 的覆盖率为 93%，因为某项提供商安全过滤机制拒绝了部分漏洞利用构造请求。

这一细节揭示了另一项生产环境约束。安全智能体有时需要推理有害技术，以验证防御措施。模型安全控制可能阻断正当评估，从而产生不应被忽视、而应被量化衡量的缺失结果。

对于企业采购方而言，近期最合适的定位是受控辅助。让 AI 负责确定优先级、解释结果并整理证据。在高风险代码路径上仍应保留人工验证，尤其是在部署环境或业务逻辑决定攻击能否奏效时。

如此一来，价值主张会更聚焦，也更站得住脚。AI 可以缩短检索时间并提出假设，但不应仅因其输出带有自信的技术表述，就被赋予单方面决策权。

安全团队接下来应关注什么

只有当厂商测试完整系统、公布平衡的错误率，并证明其优势在真实代码库中依然有效时，这项基准测试才具有实际意义。

第一个信号是参与度。AWS 邀请开发者运行全部 14,822 个样本，并提交预测结果以获得验证评分。配备工具的多步骤系统将与单轮模型分开评估。

独立提交的结果将揭示，智能体式验证是否能够弥合已测得的差距。如果完整系统能将两类错误率都降至 10% 以下，结果将支持 AWS 的观点：系统架构可以弥补基础判断能力的不足。如果做不到，信任问题就更为深层。

第二个信号是可复现性。研究人员应审查已发布的样本、挑战类别、未评分样本池以及隐藏标签流程。来自独立团队的可比评估将说明，模型排名和失败模式是否能在 AWS 的构建方法之外持续存在。

第三个信号是生产环境证据。厂商应披露用户调查、忽略、重新打开并最终修复了多少告警。这些工作流结果比模型孤立的分类得分更重要。

这项基准测试也让采购方能够提出更好的征询要求。要求厂商提交其系统，并分享经验证的误报率和漏报率。随后再询问：面对关键代码、受环境条件限制的发现，以及不受支持的编程语言时，其验证流程将如何变化。

开发者应关注工具如何呈现不确定性。一名有用的审查者应区分已确认的漏洞利用路径、合理的疑虑以及缺失的上下文。将这些类别视为相同，会制造本可避免的工作，也会掩盖系统真实的置信度。

AWS 关于 AI 漏洞检测的研究并未表明 AI 安全审查毫无用处。它表明，缺乏严格验证的检测为何依然昂贵且风险很高。

下一轮检验属于产品团队和采购方。在将某项发现作为紧急工作交给工程师之前，应要求证据证明它经得起代码追踪、环境检查和可复现验证。你的安全厂商会公布两类错误，还是继续兜售速度，却不披露背后的审查队列？