您是担心大模型代码生成安全与成本问题的 CISO 或工程负责人吗？

在全面采用某款 AI 模型之前，请先查阅我们专有的 LLM 基准测试数据——SCW AI 信任指数

网络安全行业正处于不堪重负的状态，Anthropic 的 Mythos（以及迅速被封禁又发布的 Fable 5）等工具，促使许多安全领导者开始迅速增强其安全计划，以应对 AI 技术带来的代码生产量激增，以及漏洞利用速度的巨大变化。

在这种情况下，人们很容易倾向于采取预防性（坦白说，也是被动性）的安全措施，以应对感知到的 AI 驱动的违规风险。然而，当今有一个更为普遍的问题可能影响着每一位 CISO：在软件生产环境中选择何种 LLM 模型。虽然 影子 AI 的后果已广为人知，但这只是令人担忧的风险图景的一部分。我们不应该一边支付 Token 来生成代码，一边又支付更多 Token 使用 AI 来查找安全编码问题，然后再支付 Token 来生成并应用安全修复。每种 AI 模型在产生弱点和漏洞的频率上都各不相同，尤其是在跨框架或编程语言比较性能时。因此，必须确定合适的模型选择，以支持现有的技术栈、语言和框架，而这些信息在目前很难获取。

Secure Code Warrior partnered with key researchers at RMIT University, and we’ve spent months asking a deceptively simple question: when you hand your codebase over to an AI model, exactly how much security risk are you inheriting? The answer, based on our empirical study of 1700+ complete application codebases generated across leading frontier and budget models and eleven language frameworks, is: more than you think, and in ways that will surprise you.

在将你的安全计划带入 AI 时代时，请务必从我们的研究报告中汲取以下五点：

1. 成本不能代表安全性。

人们很容易认为支付更高的费用就能买到更安全的代码。但我们的数据表明，事实更为微妙。在我们的原始研究中，GPT 5.1 的平均运行成本为 5.60 美元，却获得了 79.6 分（满分 100 分）的最高标准化安全评分。而 Claude Sonnet 4.5 的平均运行成本为 43.99 美元，评分却仅为 71.2 分。这意味着为了更差的安全结果，却支付了近 8 倍的成本。

成本差距并非仅仅由每 Token 定价驱动。以 Anthropic 模型为例，它们在智能体编码循环中执行了更多的工具调用，Sonnet 4.5 运行期间生成了 1.76 亿个输出 Token，而 GPT 5.1 仅为 4200 万个。更多的活动、更多的 Token 和更高的成本并没有带来更高的安全性。预算不等于质量，所以不要让它成为衡量标准的替代品。

2. 每个模型都有其“漏洞指纹”。

在超过 1700 个代码库和 16 个模型中，我们识别出了 83 个具有已验证真阳性结果的独特 CWE 类别。这些并非随机出现；每个模型都表现出一种系统性的模式，且无论框架或语言如何，这种模式都会持续存在。在我们最初的 6 模型研究中，所识别出的 87 个 CWE 类别中有 39 个是由所有测试模型共同产生的，这表明很大一部分漏洞类型是与模型无关的，而非特定于供应商。例如，Anthropic 的 Claude 模型表现出硬编码凭据（CWE-798）的反复倾向。Gemini 2.5 Flash 则始终会在生产版本中遗留调试代码（CWE-489）。

这些指纹表明，这更多是源于训练数据或对齐方式的偏差，而非随机噪声。这种可预测性实际上很有用：一旦了解了模型的盲点，你就可以针对性地配置扫描规则和生成后的检查机制。

3. 某些漏洞是普遍存在的……且没有一个测试模型能避免它们。

例如，在我们当前的动态指数中，最普遍的发现之一是 CWE-532（将敏感信息插入日志文件），它已作为真阳性出现了 6,765 次。

每个模型都是基于相同的普通应用程序规范进行工作的，这就像产品团队每天编写的简单语言简报，而不是安全检查清单，也不是旨在诱导失败的精简提示词。这些漏洞大多不是异国情调的边缘案例，而是遗漏导致的失败：留在源码中的凭据、过于宽松的默认设置、缺失的授权检查；这些差距只要你明确要求，模型就能立即弥补，因为模型不会仅凭普通规范自行推断出这些要求。唯一的例外是上述最主要的发现：记录敏感数据并不是模型“忘记”添加的，而是它们主动编写的，就像一个不熟练的人类开发人员可能会做的那样。这是模型在没有人类明确要求的情况下主动采取的行为。模型忠实地执行了提示词中描述的内容，包括所有从安全加固角度未提及的部分。

4. 框架环境决定了模型表现。

这一发现应该重塑组织对 AI 辅助开发的看法。研究清楚地表明，模型优势会随技术栈的不同而变化。一个在某个框架中表现良好的模型，在另一个框架中可能会表现不佳，因此团队应该在实际使用的环境中评估模型。

在我们当前的 SCW AI 信任指数中，框架之间的差距远大于模型之间的差距。JavaScript Basic（汇总了我们测试的所有 13 个模型）的总风险评分为 6,770。而研究中最安全的框架 C#/.NET Basic 的评分仅为 111。仅因框架选择的不同，安全风险就存在 61 倍的差异。

Our original study found the likely reason why: frameworks with opinionated security defaults, e.g., C# with ASP.NET's built-in anti-forgery tokens, Java Spring's declarative security model, produced dramatically safer code regardless of which model generated it. Raw environments like JavaScript Basic amplify model differences catastrophically. Choose your framework with security intent first, if possible, in your organization.

5. 没有哪种模型在所有场景下都表现最优，模型选择必须结合具体框架进行考量。

在我们的原始研究中，GPT 5.1 总体领先，但在 Swift iOS 方面排名垫底。Sonnet 4.5 生成了整个研究中最安全的 Java Spring 代码，但在 Java EE API 中却排名最后。Gemini 2.5 Pro 在 Python 和 Swift 领域表现卓越，但在 Java 方面表现平平。不存在绝对安全的通用模型。

拥有多语言代码库的组织要么必须接受各技术栈中存在的模型特定盲点，要么采取路由策略，为每个框架匹配在该上下文中具有最强安全性的模型。无论选择哪种模型，安全扫描都是必不可少的。即使是表现最好的模型，在我们测试的每一个框架中也都会产生已验证的漏洞。

这种成本压力不会消失。随着代理工作流的扩展，账单也会随之增加：更多的工具调用次数、更多的重新生成周期、每个任务消耗更多的 Token。可以预见，不断上涨的单任务和单 Token 成本将促使一些组织为了控制支出而转向使用更旧或更便宜的模型。我们的数据表明，这一决策必须基于证据而非直觉：GPT 5 Mini 在我们最初的研究中既是最便宜的模型，也是我们测试中最不安全的模型。成本压力是客观存在的，你必须让它驱动你去进行衡量，而不是盲目猜测。

问题从来不在于是否需要扫描；相反，安全领导者必须优先收集正确的数据、风险信号和 AI 可观测性，以明确首先需要扫描的内容。这正是 AI 治理发挥重要作用的地方，我们拥有全面的解决方案，可以立即提供这些关键信息。‍

‍

>>> 了解更多: SCW Trust Agent: AI
>>> 下载: 电子书
>>> 探索: 我们的基准测试微型网站 (完整研究报告将在此处链接)