对抗韧性评分：AI生成代码的新指标
“这个AI能写出安全代码”的问题所在
每个AI编码工具现在都宣称自己具备某种程度的安全意识。但几乎没有一个工具会用具体的数字告诉你，它刚写出的代码到底有多强的韧性——更少有工具能让你事后自行验证这个数字。正是为了填补这个缺口，我设计了对抗韧性评分（ARS）。它是GAUNTLEX背后的核心指标，我想详细说明它的计算方式——不是营销版本，而是实际公式——因为一个无人能审计的安全指标根本算不上指标，只是空口声明而已。
计算公式
ARS = Σ(攻击得分) / N
其中N是针对某次运行生成的代码所发起的对抗攻击次数（快速模式为5次，标准模式为20次，彻底模式为50次），而每次攻击的得分只能是以下三个值之一：
- 1.0 — 已缓解。攻击被完全防御。
- 0.5 — 部分缓解。存在防御，但可被绕过或不够完整。
- 0.0 — 未检测到。完全没有防御；攻击完全成功。
每次攻击由GAUNTLEX的Arbiter独立评分——这是一个单独的模型调用，它会给出裁决（已缓解 / 部分缓解 / 未检测到）以及一行原因说明，因此每个得分都附带解释，不仅仅是数字。
ARS是这些得分的平均值，因此落在 [0.0, 1.0] 区间内。
为什么是平均值，而非通过率
我认为这一点最重要，但也最容易被忽略。ARS不是“被拦截的攻击百分比”。通过/失败的计数方式会丢弃信息——它把90%的防御效果等同于完全没有防御，把勉强避开的绕过等同于从未有机会成功的攻击。对每次攻击的连续得分进行平均，保留了这种梯度。一个能干净利落地缓解大部分攻击、但有两次防御可被部分绕过的代码库，与一个能完全拦截某些攻击、而对另一些攻击完全失败的代码库相比——即使原始计数类似，前者的得分也不同，且更具信息量。
它同时也意味着 ARS 能够抵抗通过测试选择进行的操纵。你无法通过堆砌大量无关紧要的被拦攻击来注水分数，因为如果一个严重的攻击（比如认证绕过）完全未被拦截，无论周围有多少轻松通过的攻击，都会大幅拉低平均分。
大门，而非建议
GAUNTLEX 在 CI（持续集成）中运行，并带有一个可配置的最低 ARS——默认为 0.80。如果某次运行的得分低于该阈值，构建就会失败。不是警告，也不是稍后审查的 Slack 通知——合并被阻断，就像失败的测试套件阻断合并一样。fail_open 默认值为 false：如果 GAUNTLEX 本身因某些原因无法完成一次运行，那也是失败状态，而非静默通过。
理由：一个仅作为建议的安全性评分在 deadline 压力下每次都会被忽略。一个能阻断合并的评分则不存在这个问题。
领域特定，而非通用
每次运行中的 5/20/50 个攻击并非通用模糊测试——它们来自针对特定监管或安全领域范围的政策剧本：OWASP Top 10、HIPAA、FINRA、PCI DSS、SOC 2（NIST SSDF 和 OWASP API Security 可作为可安装扩展提供）。每个领域剧本都是一组精选的场景，专门针对该领域的实际故障模式——HIPAA 的剧本探测 PHI（受保护健康信息）处理故障模式，FINRA 的剧本探测那些法规真正关心的记录保留和审计追踪模式，而不是一个贴上不同标签的 OWASP 列表翻版。
GAUNTLEX 产生的每一个发现还带有 CWE（通用弱点枚举）标签，并映射到控制框架（NIST SSDF、OWASP SAMM、SOC 2、ISO 27001）——因此一份报告不仅仅是“这是分数”，而是合规审核员可以实际追溯到特定控制项的内容。