AI 安全需要第二种意见

AI 编写软件的速度已经超过了我们保障其安全的速度。你跟得上吗？

等你读完这句话，开发者及其 AI 智能体就会提交两千条左右的代码更改。去年此时，这个数字大约是 150 条。

过去一年，AI 生成软件的发展速度惊人。GitHub 记录显示，仅 2026 年 9 月就有 73.8 亿次提交，是前一年同期总量的五倍多。这一爆发式增长对安全造成的影响十分深远。每一次提交都是一段理应有人理解、维护并保障安全的代码。Cloud Security Alliance发现，《财富》美国 50 强企业中，借助 AI 的开发者提交代码的速度是同行的三到四倍，而他们每月发现的安全问题数量则增加了约十倍。

现在想想，谁要承担随之而来的工作量增长。CISO 团队的人数和一年前一样，但积压的工作却不是。漏洞报告不断增加，每月修复的问题越来越少，尚未解决的严重漏洞也在增多。难怪 Gartner 表示，CISO 职业倦怠正成为一项重大的运营风险。

追逐最新模型的诱惑

数字如此庞大，人们很容易本能地追求更大的数字：发现更多问题、覆盖更多范围、执行更多扫描。但这就像在一艘正在下沉的船上拼命舀水，还要求换个更大的桶；而你真正需要做的，是找到漏水处。衡量安全计划的标准，不是它发现了多少问题，而是它发现的问题中有多少确实存在，以及最严重的问题中有多少真正得到修复。

前沿 AI 模型凭借概率推理，在发现新型漏洞利用方式和未收录的缺陷方面表现出色。但其结果并不稳定。根据Checkmarx 的研究，对同一段代码运行五次相同的扫描，所得结果只有约三分之一相同。

正因为结果不一致，基于规则的分析仍然重要。它不像前沿 AI 那么灵活，但每次都会以相同方式应用经过验证的逻辑，因此团队可以信任并核验结果。AI 能发现规则遗漏的问题，例如以陌生形式出现的常见弱点，或只有在代码的不同部分相互作用时才会被利用的缺陷。AI 与基于规则的分析相结合，能发现更多重要问题，同时减少误报。

这并不是在反对 AI，而是在强调安全需要第二种意见。无论你选择哪种引擎，都要用三个问题来检验它。

问题一：可信度

扫描器指出问题时，值得你花时间处理吗？

可信度关乎信任。一项并不存在的发现，会耗费开发者一个下午的时间，也会让安全团队损失更多信誉。规模一大，误报就会让团队不再认真对待警报。警报只会像“狼来了”一样，最终淹没在背景杂音中。

这正是结果一致性至关重要的原因。对同一段代码，确定性分析每次都会给出相同答案，这有助于建立信任，也便于审计结果。

问题二：准确性

你是否找全了最重要的问题？

可信度能告诉你一项发现是否值得花时间处理，却无法告诉你扫描器漏掉了什么。我们采用一种源自数据科学的实用衡量指标，称为 F1 分数。F1 根据两个因素，以 1 到 0 的范围评估表现：

• 精确率：报告的问题中确实存在的比例。精确率高意味着误报较少。
• 召回率：扫描器实际发现的真实漏洞占全部真实漏洞的比例。召回率高意味着遗漏较少。

扫描器可以因为几乎什么都不报而显得精确，也可以因为把所有问题都报出来而显得全面，但这两种情况的 F1 分数都可能很低。行业平均水平约为 0.20。我们一直在努力应对这一挑战，并取得了显著成果：准确性达到标准扫描器的三到四倍。

准确性提高后，开发者后续的各项工作都会更轻松。你的团队可以少花时间核验，多花时间修复。

问题三：投资回报率

如何最大限度地利用投资和资源？

在试点阶段，这个问题最容易被忽略；到了生产环境中，它却往往最令人头疼。

前沿模型按 token 计费，无论扫描是否发现问题，都会消耗 token。按目前公布的价格，扫描一个有 100 万行代码的代码库，成本超过 1,000 美元。不同模型的 token 用量差距也很大；价格各不相同，具体取决于你选择的模型，以及模型为完成任务需要进行多少推理。

将这笔费用乘以企业中的每次代码提交、每个拉取请求和每个代码库。Uber 每年在研发上投入 34 亿美元，据报道，在推出 AI 编码工具后的几个月内，就耗尽了 2026 年全年的 AI 预算。

我们称之为“令牌税”。这就像开着法拉利去买菜：这趟路根本用不上那么强的性能，你却为此付了钱。硬编码凭据和 SQL 注入属于可预测的模式，确定性分析能够可靠地识别它们。

应用安全必须与时俱进

这正是 Checkmarx Fusion 架构背后的设计思路。基于规则的引擎能够以可重复的方式确定真实情况，成本也低于基于令牌的分析。前沿模型则专门用于处理规则无法预见的情况：新颖模式、复杂逻辑，以及结合具体情境判断漏洞是否可被利用。随后，发现结果分析层会整合这些结果，形成一组可信的发现。

确定性分析带来确定性，AI 则扩大覆盖范围。覆盖率与可信度同步提升。与单独运行的大语言模型相比，我们实现的保真度最高可达其四倍，准确率可达其两到四倍，而成本约为其三分之一。

发现问题只是起点。同样的思路也适用于预防。举个例子。让开发者在创建代码时就获得支持——也就是在他们编写代码的 IDE 中提供帮助——我们便能在问题出现之前将其拦截。同样，对于那些仍然漏网的漏洞，何不为开发者提供可直接合并的修复方案，优先解决最重要的问题？我们正在着手应对这些挑战，目标是逐步清理现有积压问题，以最少的投入尽快见效。

代码已在运行，你能跟上吗？

AI 让攻击者获得了速度优势。弥合这一差距的办法，不是再添一款工具，而是要决定整个组织如何构建和保护软件。今天编写的代码，将在未来数年支撑你的业务。对安全负责人而言，问题已不再是 AI 能让开发速度提升多少，而是你的安全项目能否跟上 AI 所创造的一切。

因此，别被数字迷惑。评估任何项目时，都要问三个问题：它发现的问题可信吗？它能否发现足够多的重要问题？在整个组织范围内实施是否切实可行？将确定性分析的精准度与前沿模型的推理能力相结合，最有望让你对这三个问题都给出肯定的回答。

软件发展的脚步不会放慢。如今，我们的任务是弥合风险差距：也就是软件创建速度与风险发现、修复速度之间的差距。