AI 如何让我们使用的软件更安全

AI 能让我们使用的软件更安全，帮助我们找到以往检查未能发现的缺陷。 Firefox 这个开发并审查多年的浏览器也遇到了这种情况：在 Anthropic 于 2026 年 3 月描述的协作中，Claude Opus 4.6 在两周内帮助识别出 22 个漏洞，Mozilla 将其中的 14 个评定为高严重性。

这并非新写就、未经测试的软件。恰恰这一点让案例值得关注：新的分析工具甚至能在成熟产品中发现问题。发现这些问题并不会让软件突然变得不安全，反而让我们有机会解决此前未知的弱点。

Firefox 的故事让我们可以顺着这个机会一路看到具体结果：在代码中发现缺陷、研究人员的验证、修复，以及最终送达用户的更新。AI 在这条链条的开端发挥作用，但收益取决于能否走完全程。

Firefox：在多年检验的软件中发现新漏洞

Anthropic 的研究人员之所以选择 Firefox，正因为它复杂、使用广泛且经过大量测试。正如他们在与 Mozilla 协作的说明中所解释的，他们从 JavaScript 引擎开始——这是执行网页代码的组件。

原因很实际：浏览器会不断处理它无法控制的内容。网页可能来自可信网站，也可能来自试图利用错误的人。因此，浏览器处理内存和代码执行的方式，是其安全性的重要组成部分。

据该说明所述，经过约二十分钟的探索，模型标记了一个可能的使用后释放（use-after-free）错误：程序可能在内存被释放后仍访问它。研究人员在虚拟机中复现了该问题，并在提交给 Mozilla 之前做了进一步检查。

重要的结果不是模型给出的令人信服的回复，而是其他人能够复现的缺陷。 正是这一区别，把假设变成有用的报告。模型指出了该去哪里寻找；验证则确认问题确实存在。

一份报告如何成为已确认的漏洞

在研究人员核查最初的发现时，模型持续产生新的待检查用例。这并不意味着每个用例都是漏洞：能让程序崩溃的输入，单靠它并不能证明有人能攻破系统。

与 Mozilla 的协作也有助于区分这些结果。Anthropic 描述在此过程中提交了 112 份独立报告，相比之下识别出的漏洞是 22 个。这是两种不同的衡量：一个描述待调查的材料，另一个描述研究过程中被确认的安全问题。

这体现了 AI 的具体贡献。它能帮助探索代码、构造测试用例，而研究人员和维护者则负责解读结果、澄清误解并决定如何应对。整个过程仍是技术性的、可验证的，并不依赖对模型的信任。

当 AI 能产出维护者可以核查的证据时，它让研究更有用。 在 Firefox 案例中，说明强调可复现的测试、问题描述和候选修复的价值。正是这些要素，让懂软件的人得以从报告走向解决方案。

发现漏洞也不等于能够利用它。在 Anthropic 描述的另一个独立实验中，模型只在两个用例里产出了利用程序，且环境中移除了一些浏览器保护（包括沙箱）。这一结果并不能证明其能自动攻破任何 Firefox 安装。它说明为什么发现、验证和利用必须被当作不同的步骤。

为什么更多被报告的漏洞并非只是坏消息

通过观察 Epoch AI 收集的漏洞数据，Firefox 案例获得了更广阔的视角。该项目使用 CVE Program 的公开记录（该计划为已知漏洞分配标识符）来跟踪漏洞随时间发布的趋势。

在其针对 2026 年 7 月的分析中，涵盖 21 家大型组织，严重漏洞从 1 月的 35 个上升到 4 月的 98 个、7 月的 606 个。高严重性漏洞在同一时期从 268 个上升到 600 个、再到 1,906 个。这些是该分析所发布表格中的数值，而非从图表中目测的估算。

这正是“Cyber Risk Goes Parabolic”这句话所描述的增长。但数据衡量的是已发布的漏洞，而非成功的攻击，也并非发现的时间。Epoch AI 说明，各组织的报告实践和分级存在差异，历史计数也可能被修订。仅凭图表无法证明增长中有多少是由 AI 造成的。

安全的进步，一部分在于让此前未知的问题变得可见。 Firefox 案例具体展示了这种可能；不断增长的披露则让处理它变得更紧迫。没有必要把每一个新 CVE 都解读为软件正在变差的证据。

决定性的问题在之后：我们如何处理已经发现的东西？如果结果只是一份更长的清单，收益仍不完整。如果报告导向修复，软件就能变得更安全。

从发现漏洞到修复 Firefox

对 Firefox 而言，这一步是有据可查的。Firefox 148 的安全公告列出了已修复的漏洞，并把若干发现归功于使用 Claude 的研究人员。工作并没有停在模型供应商的声明上，而是进入了浏览器的维护流程。

然而，修复需要的不仅是改动一行代码。团队必须确认缺陷不再发生、程序仍按预期运行。一个解决了问题却在别处引入错误的改动，还算不上好的修复。

Anthropic 的说明描述了给 AI 工具配备可靠校验的价值：既要有测试确认原问题是否仍可复现，也要有测试检测回归。通过这些检查有助于技术评审，但并不会自动让每一个模型生成的补丁都适合批准。

当发现变成经过验证并发布的修复时，它才真正改进了软件。 这正是 AI 可以在最初的研究之外继续贡献的地方——帮助准备测试和候选方案。维护者仍负责判断这些改动是否适合项目。

还剩最后一步。新版本可能已经可用，但用户还需要真正收到它。

更新必须抵达我们使用的系统

对 Firefox 用户来说，一个漏洞被修复的收益，取决于采用包含该修复的版本。发布补丁本身并不会自动改变每一份旧安装。这个区别听起来简单，但在企业里却成为一个现实的管理问题。

浏览器可能安装在许多设备上，通过不同的流程和时间表更新。在认定问题解决之前，组织需要知道还有哪些版本仍在运行、更新是否成功部署。仅仅让安全团队阅读公告、或批准一次更新，是不够的。

同样的逻辑也适用于其他软件。组件的生产者必须修复它；集成它的人必须检查兼容性；管理系统的人必须部署并核验更新。每一步都可能需要投入工作，而没有任何一步会因模型发现缺陷的速度而被自动省去。

只有修复出现在用户实际使用的软件中，用户才能真正受益。 及时更新的资产清单、清晰的责任归属和可靠的发布流程，共同完成这段旅程。AI 可以帮助比对公告与已安装版本，但它的结论必须放到真实系统上验证。

这正是研究案例如何变成企业的教训：投资于发现是有用的，前提是其结果能抵达人们每天使用的应用和设备。

AI 的价值体现在我们得以改进的软件中

Firefox 讲的并不是一个浏览器突然变得脆弱的故事。它展示的是新工具如何帮助在成熟产品中发现缺陷，以及研究者与维护者之间的协作如何把那些发现转化为修复。

这与把图表只当作警报的读法不同。更多已知漏洞也可能代表一种机会：我们此前无法处理的问题，终于变得可识别、可修复。如果分析能力增长，而验证、修复和更新的能力没有同步增长，这个机会就会流失。

当 AI 把弱点的发现与其在真实系统中的消除连接起来时，它让软件更安全。 它的价值并不止于发现的漏洞数量，而体现在那项工作之后我们仍在使用的软件质量上。