OpenAI 发布 Patch the Planet 漏洞全球协同响应框架

Patch the Planet：随着智能体发现严重漏洞，全球响应协调工作展开

在过去两个月中，我们领导了一个由维护者、研究人员和安全服务提供商组成的联盟，以解决 PHP（用于运行网站和 Web 应用程序的开源编程语言）中的严重漏洞。Calif 作为我们 Patch the Planet⁠(opens in a new window) 倡议的一部分，使用 GPT‑5.6 Sol 识别出了一个严重缺陷，Wiz 也独立发现并报告了这两个漏洞。PHP 维护人员主导了修复和发布工作，我们的团队以及 Wiz、Cloudflare 等合作伙伴则贡献了研究、技术支持和协调工作，以便在披露之前准备好保护措施。

对于使用 PHP 的组织而言，当务之急是应用修复程序。我们正在共享一个 PHP 版本检查器，并将推出配套的 Codex 技能，以帮助运营人员识别可能存在漏洞的 PHP 版本，并结合 PHP 及其提供商的指导方针，确定适用的更新。

鉴于这些缺陷的严重性以及 PHP 的广泛使用，我们认为这是近年最具影响力的安全问题之一。它凸显了人工智能如何能够发现具有互联网规模影响的安全漏洞，但同样的能力也可能帮助攻击者迅速开发出攻击工具和漏洞利用程序。

据我们所知，前沿人工智能在攻击者之前发现了这些漏洞，为维护者和安全服务提供商打开了一个防御者窗口（Defender’s Window），以便在披露之前准备好修复和保护措施。

为了帮助更多防御者利用这些能力，我们通过 Daybreak for Frontline Defenders 承诺提供 10 亿美元的补贴 Daybreak 访问权限，重点关注保护关键服务且安全资源有限的组织。

尽管这些漏洞意义重大，但它们只是我们已经发现并正在着手修复的几个重大漏洞之一，我们预计类似的发现将在未来几个月内急剧增加。结合我们迄今为止的经验，我们正在分享一种适合人工智能时代的方法，用于响应广泛使用软件中的严重漏洞，我们呼吁安全社区帮助完善这一框架。它汇集了我们的模型、安全专长和维护者，帮助将发现转化为保护措施，并构建能够随着人工智能能力提升而扩展的响应机制。

协调全球响应

将修复方案投入使用可能意味着针对旧版本进行调整、准备提供商缓解措施以及跨多个组织更新系统。随着发现更多漏洞，一个可重复的流程有助于这些团队迅速采取行动。

通过 Patch the Planet，我们贡献了安全专长和模型访问权限以支持 PHP 响应，并与维护者和研究合作伙伴合作测试修复方案并准备指导方针。我们还协助与基础设施提供商就受影响系统的保护进行协调，并与政府网络安全机构合作，以帮助指导方针传达给关键组织。这支持了以维护人员为主导的响应，并帮助其他防御者做好准备。

对于某些研究发现，研究人员可以直接与软件维护者合作调查问题并开发修复程序。另一些发现则需要更广泛的响应，因为它们会影响许多产品，或者因为分销商和服务提供商需要时间（如果前沿能力与广泛可用的能力差距不大，这些时间可能会很短）来准备更新和保护措施。在这些情况下，所提出的框架可以帮助维护者确定需要谁来参与并协调工作。响应过程可分为五个阶段：

验证并修复上游漏洞。维护者、研究人员和关键技术合作伙伴确认发现、评估其影响，并开发和测试修复程序。此过程包括使用前沿模型进行对抗性测试，以寻找绕过补丁的方法以及该漏洞的相关变体。
给予受影响的组织采取行动的时间。我们提出了一个框架，用于考虑哪些组织需要提前获取信息以准备保护措施，同时由维护者决定让谁参与。我们协助进行外展联络、信息共享协议以及各团队之间的协调。分销商可能会针对旧版本调整修复程序，托管服务提供商可能会测试缓解措施，安全提供商可能会准备检测或预防措施，包括网络应用防火墙（WAF）规则。
与政府合作伙伴协调以帮助保护关键系统。政府机构在协调更广泛的响应以及帮助安全指南传达给负责关键基础设施和其他基本服务的组织方面发挥着至关重要的作用。以 PHP 为例，我们与合作伙伴协作，与美国政府的多个部门进行了接触，包括白宫超级智能部队（Super Intelligence Force）、国家网络总监办公室（ONCD）、网络安全和基础设施安全局（CISA），以及国际合作伙伴，以支持这一工作。
跨受影响产品准备更新。随着修复程序、指南和披露计划趋于稳定，维护者可以引入更多的分销商、托管和服务提供商、响应团队以及运营商，以准备更新并填补覆盖盲区。
一旦补丁可用，发布指南并支持部署。公开指南有助于人们评估其暴露情况、找到权威更新或临时缓解措施，并检查修复程序是否正在运行。随着运营商部署更新并报告其需要帮助的地方，响应工作将继续进行。

所提出的框架考虑了一个组织的保护角色，包括保护其自身系统和客户、采取行动所需的时间以及处理敏感信息的能力。同样的标准也适用于同类组织，由维护者在披露之前决定让谁参与。

每个参与者都会收到开展保护工作所需的信息，从带有入侵指标的网络日志到更敏感的工作验证概念攻击载体。即使是有限的细节也可能暴露漏洞，因此我们需要权衡共享这些信息的风险与它们所带来的保护作用。

遵循该框架的团队将与维护者合作，为防御者争取准备时间，并且如果在野外存在积极利用、发生泄露、出现暴露性公开补丁，或者因修复停滞而导致用户面临的风险增加，则重新评估时间表。

Patch the Planet 网站⁠（在新窗口中打开）汇集了公开披露的信息和指南，可帮助运维人员识别受影响的系统、找到合适的更新，并验证更新后的软件是否正常运行. 对于 PHP，它指向维护人员官方的补丁和升级说明以及我们合作伙伴的技术研究. 该指南还涵盖了临时缓解措施、何时引入提供商或专家，以及备份和恢复. 临时保护措施可以降低风险，但我们会明确指出其局限性和运维权衡.

运维人员可以参考 CISA 关于优先级和修补的指导意见⁠（在新窗口中打开），根据暴露情况、漏洞利用情况和潜在影响来评估行动的紧急程度. 这可能意味着紧急打补丁、立即采取缓解措施或计划更新，同时在有必要时进行取证分类，以评估系统是否已被入侵. 随着情况的变化，应重新评估优先级，并找到彻底修复的明确路径.

赋予维护人员响应的能力和资源

全球协同取决于维护软件的人员. 许多项目由小型团队运营，他们在进行常规开发的同时还要审查安全报告. 这些团队需要帮助来区分新问题和重复问题、评估影响，以及在受支持的版本中测试修复方案. 我们通过提供资金、访问高性能模型的权限以及直接的技术工程帮助来支持这项工作.

强大的 AI 功能正在整个行业不断推进，我们期望 AI 在帮助防御者发现漏洞、监控系统和应对威胁方面发挥越来越大的作用. 我们正在投资模型、工具和合作伙伴关系，以帮助防御者将这些功能投入使用.

我们的投资包括通过 Codex for OSS 为所有维护人员提供订阅，以及直接赞助诸如 Rust Foundation⁠（在新窗口中打开）等项目，用于支持维护人员和技术工作. 每个项目都设定自己的优先级. 可重复使用的测试和安全工作流可以减少处理未来发现的问题所需的精力. 开源项目可以申请加入 Patch the Planet⁠（在新窗口中打开）以获得动手支持.

我们还在为 Daybreak 校准额外的拦截分类器，以帮助减少被滥用的可能性. 这涉及艰难的权衡：旨在防止滥用的安全措施也可能会阻挡合法的安全工作. 广泛访问高性能模型与针对滥用的有效保护措施两者同样至关重要. 我们的目标是在限制有害使用的同时，保留防御者发现和修复漏洞所需的功能. 随着能力的提升以及我们从这些工具的使用方式中吸取经验，我们将继续优化这种平衡.

构建更安全的软件基础

随着模型变得更加强大，机遇已不仅仅局限于发现和修复单个漏洞. 我们希望帮助工程师从一开始就构建更安全的软件. 对广泛使用的组件进行改进可以防止漏洞或限制其对许多产品和服务的影响.

AI 可以帮助工程师理解现有代码、准备变更并开发测试，而维护人员和安全专家则负责验证这些变更是否保留了用户所依赖的行为. 我们在几个领域看到了机遇：

从源头保障代码安全。编码模型可以帮助开发者选择更安全的默认设置、正确使用安全库，并在编写时捕捉危险模式。在开发过程中预防漏洞，意味着维护人员和用户需要进行的紧急修复更少。
内存安全软件。将关键组件迁移到内存安全语言可以消除常见类别的内存错误。AI 可以协助迁移、进行测试以及由专家审查来检查行为和兼容性。
形式化验证。数学证明可以表明关键组件在既定假设下满足特定的安全属性。将这些方法应用于广泛使用的组件，可以帮助排除依赖它们的各种服务和关键基础设施中的多类漏洞。
更强的隔离。系统需要防范尚未发现或修复的漏洞。在受严格限制的沙盒中运行处理不受信任的文件、图像或媒体的软件，可以在系统遭入侵时限制损害。AI 可以帮助工程师测试和加强广泛使用的沙盒技术，从而改善许多应用程序的保护措施。

帮助我们改进这一方法

我们分享我们的方法，是为了让维护人员、研究人员、响应团队、服务商和运营商能够共同使其切实可行。我们希望了解它在哪些地方能提供帮助、在哪些地方会增加延迟或负担，以及我们遗漏了什么。来自以往漏洞披露的示例将特别有用。

我们对以下方面尤其感兴趣：

披露窗口。维护人员、运营商和防御者需要多少时间来准备和部署可靠的修复程序？什么证据应该触发更早的披露，特别是当某些用户能够比其他用户更早受到保护时？
紧急修补。在失去管理权限之后，政府或其他运营商在什么情况下（如果有的话）应该利用漏洞来修补他们拥有或授权管理的系统？应当适用哪些保障措施？我们可以想象这样一个最终状态：对全网进行全天候的已知漏洞扫描，并在检测到漏洞时通知网站所有者或直接修补系统。
提前通知。谁需要提前预警以便采取有用的保护行动，包括我们可能遗漏的防御者？分阶段通知在什么时候比同时通知更广泛的群体效果更好，我们又该如何在覆盖范围与泄露风险之间权衡？
默认安全的软件包。在等待上游修复的同时，我们如何帮助识别和修复下游软件包中的漏洞，或者将修复程序反向移植到不再接受安全更新的旧版本？当无法及时升级时，需要进行哪些测试和维护才能使这些软件包成为可靠的选择？

我们也欢迎推荐能够审查该方法、对其假设提出质疑并找出漏洞的独立安全专家。您的意见将帮助我们完善应对措施并确定支持的优先级。在此分享您的反馈⁠（在新窗口中打开）。

作者

OpenAI