Schneier 的 AI 漏洞发现主张让软件修复承压

Bruce Schneier 11 月 2 日的文章摘要聚焦于一项令人震惊的主张：有记录以来的关键软件漏洞中，3% 是在一个月内发现的。其 AI Vulnerability Finding 文章所附的摘录还预测，每年将新增约 10 万项发现。这些数字尚未在此得到验证，但已有记录的发现结果已令负责修复软件的团队面临压力。

核心矛盾在于发现速度与修复能力之间的差距。发现安全缺陷意味着有机会保护用户，但也带来工作：必须有人验证报告、评估暴露面、审查修复方案，并交付更新。发现环节的自动化，并不会自动加快之后的每一项决策。

Anthropic、Google 和 Mozilla 提供了有用的参考点，尽管它们的数字衡量的是不同内容。它们的公开材料支持一个更为审慎、但影响重大的结论：自动化安全研究正在产出真实发现，但统计方法和后续结果仍需要严格审视。对于开发者和企业采购方而言，问题在于更快的发现是否能转化为更少的暴露风险。

AI 漏洞发现主张实际证明了什么

这一标题统计数字是一条研究线索，并非对全球关键软件缺陷作出的独立确证性衡量。

与 Schneier 的漏洞发现文章相关的所提供摘录，将这些数字表述为一则评论。本文审查未能获取原始页面。因此，该摘录无法说明百分比由谁计算、统计了哪些记录，或如何界定报告期。

这一差异限制了能够基于该主张负责任地得出的结论。一个引人注目的百分比，可能准确描述某个特定数据库，却无法描述曾经发现的每一个安全漏洞。当读者悄然以更大的总体替代原始分母时，它也可能产生误导。

发现、披露和数据库发布是不同事件。研究人员可能在供应商确认前私下识别出缺陷。公开文档可能在之后才出现，并与软件更新同步发布。因此，某个月的发布量激增，并不能证明所有相关缺陷都在该月被发现。

“有记录以来的全部历史”这一措辞还引入了另一项尚未解决的边界问题。可审计的计算需要明确命名的数据库、带日期的快照，以及一致的纳入规则。它还需要解释重复记录、被拒绝的提交，以及发布后严重性发生变化的漏洞如何处理。

年度预测引入了另一项假设：近期的速度将持续下去。即使最初的月度计数被证明准确，这一假设也值得检验。集中的研究活动、发布积压或协调发布，都可能造成短期激增，却不足以证明存在稳定的年度速率。

这里也存在分类问题。摘录开头谈的是关键漏洞，随后却更宽泛地提及错误和历史漏洞总数。在核查底层计算前，这些类别不能相互替换。软件缺陷、已确认的安全漏洞和关键漏洞，描述的是不同总体。

这些限制都不意味着更广泛的发展不重要。它们界定了可信度应止步的位置。能够站得住脚的叙述，应聚焦于有记录的发现活动及其运营后果，而不是关于一个被精确衡量的历史转折点的无依据主张。

对于通过社交媒体帖子接触 AI Vulnerability Finding 的读者而言，这一区分能够保护其中有价值的洞见。安全团队有理由立即审视自身能力；在调查自身发现与修复流程是否正在失衡之前，他们并不需要先接受一个未经验证的百分比。

Anthropic 报告的结果显示了规模，但也存在重要边界

Anthropic 公布的数字支持其发现规模可观这一主张，但并不能验证该评论中的历史百分比或月度外推。

在其 10 月 6 日发布的网络安全验证计划公告中，Anthropic 报告称，4 月至 7 月期间，其合作伙伴中至少验证了 129,000 个软件漏洞。该公司还单独报告称，4 月至 10 月期间，其开源扫描发现了 5,500 项已验证问题。

该公司称，超过 33,000 个已验证漏洞被评为关键或高严重性。这些是公司自行报告的结果，而非经独立复现的人口普查。其时间范围和类别也不同于所提供评论中关于一个月内发现关键漏洞的主张。

Anthropic 披露了实质性限制。其影响报告基于 33 家合作伙伴提供的部分信息，而不同组织采用了不同的分级处理方法。提供已修复数量的机构不足一半。因此，该公司将所报告的修复率描述为明显不完整。

这些边界很重要，因为不同指标回答的是不同问题。发现数量衡量的是报告的发现产出；确认数量增加了验证步骤；修复数量描述的是更晚发生的结果，而部署证据则关系到受影响用户是否真正获得保护。

因此，竞争层面的含义应保持狭窄。Anthropic 报告的是参与组织使用其模型所取得的结果。Google 的威胁研究人员考察的是更广泛的披露和利用模式。这些出版物提供互补视角，但两者都没有给出受控比较，证明哪一家供应商带来了更好的安全结果。

对采购方而言，这意味着发现总量应成为讨论的起点，而非结论。能够生成更多发现的供应商，可能发现被忽视的问题；它也可能需要客户投入更多审查时间，尤其是在报告缺乏清晰复现证据或受影响版本信息时。

一项有价值的评估应当区分新的、被接受的漏洞与已知问题和重复报告。它还应区分建议的修复与经过审查的修复。这些区分会使比较更困难，但能将技术产出与客户必须承担的工作联系起来。

压力尤其会落在那些拥有重要软件、却没有庞大专职安全团队的组织身上。发现能力可以购买或借用，但接受报告并修改产品的责任仍必须由某一方承担，即使最初分析是自动送达的。

这是从所报告规模中得出的分析性含义，而非对全行业人员配置结果的衡量。如果输入的已验证报告增加，而审查能力保持不变，未解决队列就会增长。具体速率取决于每个组织的软件、工具以及安全实施变更的能力。

这正是为何 Anthropic 公告最有价值的后续问题关乎完成情况：有多少被接受的问题进入了受支持版本？它们未解决了多长时间？在没有可比答案的情况下，大规模发现数字更清楚地证明了活动量，而非风险暴露已经降低。

软件维护者在发现之后接手后续工作

维护易受攻击软件的组织，承担着将报告转化为保护措施的运营负担。

NIST 在 4 月 15 日发布的漏洞数据库变更说明了安全工作周边信息基础设施所承受的压力。该机构报告称，2020 年至 2025 年间，漏洞提交量增长了 263%。它表示，即使处理产出提高，仍无法跟上增长速度。

NIST 调整了其在国家漏洞数据库中丰富条目内容的方式，该数据库是其公开的漏洞信息存储库。信息丰富工作会补充严重性评分和受影响产品等细节。在调整后的方法下，特定类别将获得优先处理，其他条目则会被列出，但不会立即得到补充信息。

该机构优先处理已知被利用的漏洞、联邦政府内部使用的软件，以及界定范围内的关键软件。它还承认，这些标准无法涵盖每一个可能具有重大影响的问题。这一变更记录了能力约束；它并不能证明 AI 导致了底层提交量增长。

更广泛的含义在于，持续增长的发现流需要的不只是更多数据库条目。维护者和客户需要可靠的背景信息，以决定哪些问题值得关注。缺失或延迟的背景信息，可能会将解释工作转移给已经负责评估自身系统的团队。

对软件维护者而言，收到可信报告会带来多项义务，不能简单归结为阅读其结论。必须理解受影响的行为；提出的修复方案必须契合周边设计；受支持版本和依赖组件可能需要分别作出决策。

企业用户还面临另一层解读工作。易受攻击的组件可能存在于其购买而非直接维护的产品中。他们需要知道哪些已安装版本受影响、易受攻击行为是否可被触发，以及其供应商支持采取何种行动。

这些是说明性的运营依赖关系，并非表明每个组织都在经历相同的积压。其重要性源于发现与修复之间的区别；修复是纠正或降低漏洞风险的过程。只有当有人能够就报告作出知情决策时，报告才具有价值。

激励错配值得关注。发现平台可以立即展示发现成果，而维护者因谨慎审查和波澜不惊的更新获得的可见认可较少。采购方应认识到，报告量和维护质量代表着对安全性的不同贡献。

当决策跨团队进行时，共享文档便会发挥作用。一个可搜索的知识库可以帮助关联技术记录、所有权决策和支持证据。它有助于协调；验证和发布审批仍需要相应的工程流程。

实际压力既是组织层面的，也是技术层面的。更快的发现速度迫使组织更清晰地界定报告、修复和部署决策的责任归属。当这些责任仍然模糊时，更大规模的正当发现流可能会先暴露响应流程中的弱点，之后才改善产品。

Mozilla 说明为何一项发现需要完整的修复流程

Mozilla 的说明提供了一个具体案例：AI 辅助发现如何与已交付的软件变更相连。

Mozilla 的Firefox 加固流程报告描述了将模型与测试基础设施及其安全漏洞生命周期整合的过程。该团队表示，要实现有价值的规模，需要可复现的测试、重复检测、分级处理、跟踪和发布工作。其报告称，已在 Firefox 150 中修复了 271 项 Mythos Preview 发现。

同一账户还解释了为何必须谨慎对待数据库总数：Mozilla 会将多个内部报告的漏洞归入共同的漏洞标识符。因此，其报告的漏洞数量并不直接对应公开标识符的数量。若在未说明这种关系的情况下统计任一群体，都可能误导读者。

Mozilla 还区分了严重漏洞与实际攻破。其分层浏览器设计意味着，攻击者可能需要利用多个漏洞才能跨越保护边界。高严重性分类意味着问题值得处理；它并不能证明完整攻击已经被构建出来。

这些已报告的细节构成了比单纯发现数量更有价值的案例研究。它们展示了维护者如何讨论从自动化发现到发布之间发生的事情，也揭示了模型的输出在用户获得修复前必须进入的制度性知识体系。

分析上的启示是，模型能力与组织能力会相互放大。若无人能够复现或评估，一个发现真实问题的系统所提供的保护仍然有限。成熟的响应流程能从以工程师可用形式交付的证据中获得更多收益。

这种关系也使采购比较变得复杂。在精心准备的项目环境中评估的模型，可以利用构建工具、测试基础设施以及理解代码的维护者。客户不能假定，只要将同一个模型用于陌生应用程序，就能获得同等结果。

设想一份涉及被广泛复用库的假设性报告。初始证据可能证明测试环境中存在崩溃。维护者仍需理解原因、确定受影响版本，并判断建议的修复是否解决了根本问题。

回归测试，即防止已知缺陷再次引入的检查，将有助于维持修复效果。发布沟通需要准确描述受影响的行为。下游用户随后还需要一条适合整合该库产品的更新路径。

这个假设性示例旨在解释工作流程，而非声称发生了另一宗真实事件。它说明同一项发现为何会为研究人员、库维护者、产品供应商和企业运营者带来工作。每一方都掌控着通往保护路径中的不同环节。

这里存在一个潜在的正向循环。更好的证据可以减少解读报告所花的时间，从而为实际修复腾出更多注意力。经审查的修复和有用的测试，随后又能改善后续自动化分析可用的环境。这个循环是否实现，取决于实施情况和可衡量的结果。

反向情况也同样可能发生。包装不佳的发现可能消耗原本应用于解决更强报告的注意力。关键区别并不只是人工研究与自动化研究之分，而是能够帮助维护者采取行动的证据，与将未解决调查工作转移给接收者的输出之间的区别。

严重性标签无法弥合验证缺口

关键级标签、公开标识符和已观察到的利用描述的是安全问题的不同维度。

通用漏洞评分系统（CVSS）是一个通过既定技术特征描述漏洞严重性的框架。FIRST 的严重性评分规范将关键级评分界定在 9.0 至 10.0 之间。但仅凭该分类，无法证明攻击者是否正在针对某个特定组织利用漏洞。

同样，CVE，即“常见漏洞与暴露”标识符，为公开披露的漏洞提供了共同引用。它并不是技术范围完全一致的通用单位。数量在一定程度上取决于问题被分配和呈现的方式。

因此，要严谨评估原始百分比，就需要在时间维度上采用一致规则。分子和分母必须使用可兼容的总体与严重性定义。否则，计算可能将不同类记录混合在一起，却显得十分精确。

还有一个同样重要的时间问题。如果分子统计的是近期发布的记录，它衡量的是发布活动。若称之为发现活动，则需要关于底层问题何时被发现的额外证据。报告延迟可能使这两个事件相隔甚远。

Google 在 9 月 30 日发布的披露与利用分析提供了更广泛的背景。其研究人员报告称，2026 年 1 月有 5,045 项披露，8 月有 10,740 项。他们还警告说，分配政策和供应商发布周期会使原始总数的解读变得复杂。

研究人员对利用情况进行了单独追踪，并使用了自己的风险评级，而不是 CVSS 类别。这一方法论区别很重要：其分析中的风险类别不应被悄然重新标记为关键级严重性评分。相似的措辞并不能让不同分类系统变得可以互换。

这些发现支持对因果主张保持谨慎。披露数量增加可以与 AI 使用增加同时发生，但这并不能证明 AI 解释了全部增长。报告行为、覆盖范围和发布实践的变化也需要审视。

已观察到的利用也有其局限性。某漏洞未出现在监测数据集中，并不意味着它安全或未被触及。反过来，巨大的披露总数也不能证明成功攻破同样大幅增加。可见性和抽样会影响研究人员能够观察到的内容。

因此，最有力的怀疑立场是在承认真实技术进步的同时，要求严格衡量。它并不要求否定每一份公司报告，而是要求证据能够支持所提出的具体结论，尤其当该结论延伸至历史总数或未来年度产出时。

对于 AI Vulnerability Finding，尚未解决的问题不是自动化系统能否识别真实漏洞。引用的项目说明已经支持这一较窄的主张。不确定性在于可比较总体中的规模、增长应归因于谁，以及发现以何种速度转化为持久保护。

这种区别应当塑造公共讨论。将每个漏洞都视为迫在眉睫的灾难，可能使优先级排序不堪重负。将不确定的汇总统计视为忽视已记录发现的理由，则会造成相反的错误。证据应决定主张的范围和响应的紧迫程度。

关注已确认修复、发布时间与独立复现

下一批有用证据将把发现产出与已接受发现、已交付修复和可重复结果联系起来。

未来几个月，首先应关注 Anthropic 和参与组织是否发布更完整的报告。有价值的发展将是提供配套统计，说明哪些发现已被接受、修复并纳入受支持版本。可比的报告将使现有发现主张更易评估。

更有力的说明还应解释如何处理重复报告和相关缺陷。它应将私有维护的软件与可审查文档的公共项目区分开来，也应清楚标明报告期间，避免比较重叠或规模不同的时间窗口。

如果这些信息显示，发现增长伴随着完成的修复，将增强防御能力得到提升的论据。如果已确认发现不断累积，却没有相应的发布证据，则会强化“发现速度正在超过响应速度”的担忧。仅有不完整报告会使结果仍然不确定。

其次，关注已接受报告与可用更新之间的时间差。补丁，即用于修复缺陷的软件变更，只是一个中间里程碑。受支持版本使该修复可供用户使用，而部署决定受影响环境是否实际获得它。

这些时间间隔之所以重要，是因为吞吐量可以提升，而单个问题仍可能等待过久。一个团队可能总体上关闭更多报告，却仍保留不断增长的困难案例队列。只报告已完成修复会掩盖这些未解决事项。

更短且可持续的修复周期证据，将强化自动化发现能够改善运营安全的论点。不断增长的未解决队列，或对早期修复反复进行更正，则会对其提出挑战。两种结果都值得与头条式发现总数一并关注。

第三，关注在维护资源不同的项目中进行独立复现。来自经过广泛测试的浏览器的结果具有参考价值，但并不能证明每个应用程序或库都会取得同等结果。更广泛的证据需要有文档记录的环境、已接受的发现，以及对所需工作清晰的说明。

当维护者发布自己的评估，而不是简单认可供应商总数时，复现尤其有价值。对发现有效性及其修复的共识，比产出看似令人信服结果的演示提供更多信息。分歧则可能揭示汇总统计所掩盖的局限。

这些信号提供了一种评估进展的方法，无须依赖于“最终谁受益最多”的预测。攻击者和防御者可以使用相关能力，但他们的目标和操作约束不同。结果取决于访问权限、实施情况，以及保护性变更到达受影响系统的速度。

原始评论捕捉到了围绕 AI Vulnerability Finding 的惊讶，但惊讶只是审视的起点。要求查看百分比背后的数据集。询问适用哪些严重性规则，以及日期描述的是发现还是发布。然后追踪这些发现经历确认、修复和发布的过程。若你评估安全工具，应要求提供你的团队能够复现的证据，以及维护者认可的结果。若你依赖软件供应商，应询问他们如何沟通受影响版本和已完成修复。在重复年度预测前，先阅读底层项目说明。有用的问题很具体：当发现加速时，负责你所用软件的组织能否将这些证据转化为保护？