Patch the Planet：智能体发现漏洞时的全球响应协调

# 为全球打补丁：智能体发现关键漏洞后的全球响应协调 来源：https://openai.com/index/coordinated-disclosure-of-critical-vulnerabilities/ 过去两个月中，我们带领一个由维护者、研究者和安全服务商组成的联盟，共同应对 PHP 中的关键漏洞。PHP 是一种广泛用于运行网站和 Web 应用的开源编程语言。我们利用 GPT-5.6 Sol 在我们的 [为全球打补丁](https://patchtheplanet.org/) 计划中识别出了一个关键漏洞，Wiz 也独立发现并报告了这两个漏洞。PHP 的维护者主导了修复和发布工作，我们的团队以及 Wiz、Cloudflare 等合作伙伴提供了研究、技术支持和协调工作，在漏洞披露前做好防护准备。 对于使用 PHP 的组织而言，当前的首要任务是应用修复。我们提供了一款 [PHP 版本检测工具](https://github.com/openai/php2shell-checker)，并将推出配套的 Codex skill，帮助运维人员识别可能受影响的 PHP 版本，并结合 PHP 官方及服务商的指导，确定哪些更新适用于自身环境。 鉴于这些漏洞的严重性和 PHP 的广泛使用，我们认为这是近年来影响最大的安全事件之一。这凸显了 AI 如何能够发现具有互联网规模影响的安全漏洞，但同样的能力也可能帮助攻击者快速开发攻击工具和利用代码。 据我们所知，前沿 AI 在攻击者之前发现了这些漏洞，为维护者和安全服务商创造了一个"防御者窗口"（Defender's Window，https://openai.com/index/the-defenders-window/），使其能够在漏洞披露前准备修复和防护措施。 为了让更多防御者能够使用这些能力，我们已通过 [面向一线防御者的 Daybreak](https://openai.com/index/daybreak-for-frontline-defenders/) 承诺提供 10 亿美元的补贴 [Daybreak 访问权限](https://openai.com/form/enterprise-trusted-access-for-cyber/)，重点支持那些资源有限、需要保护关键服务的组织。 尽管这些漏洞极为重要，它们只是我们已经发现并正在修复的多个重大漏洞之一，我们预计未来几个月类似发现将急剧增加。基于我们迄今积累的经验，我们分享一个适用于 AI 时代的框架提案，用于响应广泛使用软件中的关键漏洞，并邀请安全社区帮助完善这一框架。该框架将我们的模型、安全专业知识和维护者汇聚在一起，帮助将发现转化为防护能力，并构建能够随 AI 能力提升而扩展的响应体系。 ## 协调全球响应 将修复落地可能需要针对旧版本进行适配、准备服务商缓解措施，以及更新众多组织的系统。一个可重复的流程有助于这些团队在发现更多漏洞时快速行动。 通过"为全球打补丁"计划，我们贡献了安全专业知识和模型访问权限来支持 PHP 的响应工作，并与维护者和研究合作伙伴合作测试修复方案、准备指导文档。我们还协助协调基础设施提供商为受影响的系统提供防护，并与政府网络安全机构对接，确保关键组织能够收到指导。这既支持了维护者主导的响应，也帮助了其他防御者做好准备。 对于某些发现，研究者可以直接与软件维护者合作调查问题并制定修复方案。另一些则需要更广泛的响应，因为它们影响多个产品，或者因为分发商和服务提供商需要时间来准备更新和防护措施（如果前沿能力与广泛可用的能力差距不大，时间可能相当有限）。在这种情况下，所提议的框架可以帮助维护者识别需要参与的各方并协调工作。响应可以分为五个阶段： - **验证并修复上游漏洞。** 维护者、研究者和关键技术合作伙伴确认发现、评估影响，并开发和测试修复方案。这个过程包括使用前沿模型进行对抗性测试，寻找绕过补丁的方法以及漏洞的相关变体。 - **给受影响的组织留出行动时间。** 我们提议了一个框架，用于判断哪些组织需要提前获得信息以准备防护措施，同时由维护者决定邀请哪些方参与。我们协助开展外联、签署信息共享协议以及团队之间的协调。分发商可能需要为旧版本适配补丁，托管服务商可能需要测试缓解措施，安全服务商则可能需要准备检测或预防措施，包括 Web 应用防火墙（WAF）规则。 - **与政府合作伙伴协调，帮助保护关键系统。** 政府机构在协调更广泛的响应以及帮助安全指导传达给负责关键基础设施和其他重要服务的组织方面发挥着重要作用。在 PHP 这一案例中，我们与合作伙伴协作，与美国政府的多个部门进行了对接，包括白宫的超级情报力量（Super Intelligence Force）、国家网络总监办公室（ONCD）、网络安全和基础设施安全局（CISA），以及国际合作伙伴来支持这项工作。 - **在受影响的产品中准备更新。** 随着修复方案、指导文档和披露计划趋于稳定，维护者可以邀请更多分发商、托管和服务提供商、响应团队和运维人员参与准备更新并弥补覆盖范围上的缺口。 - **补丁可用后，发布指导并支持部署。** 公开的指导帮助用户评估自身暴露情况、找到权威的更新或临时缓解措施，并验证修复是否生效。当运维人员部署更新并反馈需要帮助的问题时，响应工作会持续进行。 该框架考虑了组织的防护角色（包括保护自身系统和客户的能力）、行动所需的时间以及处理敏感信息的能力。相同的评判标准将适用于同类组织，由维护者决定在披露前邀请哪些方参与。 每个参与者都会获得执行其防护工作所需的信息，从带有入侵指标（IOCs）的网络日志到更敏感的工作性概念验证（PoC）利用代码。即使是有限的细节也可能暴露漏洞，因此我们会权衡共享这些信息的风险与其所能带来的防护价值。 遵循该框架的团队将与维护者合作，为防御者留出准备时间，并在出现以下情况时重新评估时间表：漏洞正在被野外利用、发生信息泄露、公开补丁暴露了过多细节、或修复停滞给用户带来更大风险时。 [为全球打补丁网站](https://patchtheplanet.org/)汇集了公开的披露信息和指导文档，帮助运维人员识别受影响的系统、找到正确的更新，并验证更新后的软件是否正常运行。对于 PHP，网站指向维护者发布的官方补丁和升级说明，以及我们合作伙伴的技术研究。该指导还涵盖临时缓解措施、何时应引入服务商或专家，以及备份和恢复方案。临时防护可以降低风险，但我们会明确说明其局限性和运维上的权衡。 运维人员可以参考 [CISA 关于优先级排序和修复的指导](https://www.cisa.gov/news-events/directives/bod-26-04-prioritizing-security-updates-based-risk)，根据暴露情况、利用情况和潜在影响评估行动的紧迫程度。这可能意味着紧急打补丁、立即缓解或计划性更新，必要时还应进行取证分诊，以评估系统是否已被入侵。随着情况变化，应重新评估优先级，并制定明确的长效修复路径。 ## 为维护者提供响应能力和资源 全球协调取决于维护软件的人员。许多项目由小型团队运营，他们在进行日常开发的同时还要审查安全报告。这些团队需要帮助来区分新问题和重复报告、评估影响范围，以及在各受支持版本上测试修复方案。我们通过资金支持、模型访问权限和实际工程协助来支持这项工作。 强大的 AI 能力正在全行业快速发展，我们预期 AI 将在帮助防御者发现漏洞、监控系统和响应威胁方面发挥越来越大的作用。我们正在投资模型、工具和合作伙伴关系，帮助防御者利用这些能力。 我们的投资包括通过 [Codex for OSS](https://openai.com/form/codex-for-oss/) 为所有维护者提供订阅服务，以及对 [Rust 基金会](https://rustfoundation.org/media/rust-foundation-welcomes-openai-as-platinum-member-announces-donation-to-rust-project/) 等项目的直接赞助，用于支持维护者和技术工作。每个项目自行设定优先级。可复用的测试和安全工作流可以减少处理未来发现所需的工作量。开源项目可以 [申请"为全球打补丁"](https://trailofbits.com/patch-the-planet/#apply) 获得实际支持。 我们还在为 Daybreak 调校额外的阻断分类器，以降低被滥用的可能性。这涉及艰难的权衡：旨在防止滥用的安全措施也可能阻碍合法的安全工作。广泛获取强大的模型能力和有效的反滥用保护措施同样至关重要。我们的目标是保留防御者发现和修复漏洞所需的能力，同时限制有害用途。随着能力的持续提升以及我们从这些工具的实际使用中汲取经验，我们将继续完善这一平衡。 ## 构建更安全的软件基础 随着模型能力的增强，机遇远不止于发现和修复单个漏洞。我们希望帮助工程师从一开始就构建更安全的软件。对广泛使用的组件的改进可以预防漏洞或限制其对众多产品和服务的影响。 AI 可以帮助工程师理解现有代码、准备代码变更并开发测试，而维护者和安全专家则验证这些变更是否保持了用户所依赖的行为。我们在以下几个领域看到了机会： - **从源头编写安全代码。** 编码模型可以帮助开发者选择更安全的默认配置、正确使用安全库，并在编写代码时捕获危险模式。在开发阶段预防漏洞，意味着维护者和用户更少面临紧急修复。 - **内存安全软件。** 将关键组件迁移到内存安全语言可以消除常见的内存错误类别。AI 可以协助迁移工作，并通过测试和专家审查来验证行为和兼容性。 - **形式化验证。** 数学证明可以表明关键组件在既定假设下满足指定的安全属性。将这些方法应用于广泛使用的组件，有助于排除依赖于这些组件的服务和关键基础设施中的整类漏洞。 - **更强的隔离。** 系统需要防御尚未被发现或修复的漏洞。将处理不可信文件、图片或媒体的软件运行在严格限制的沙箱中，可以限制其被攻破后的损害范围。AI 可以帮助工程师测试和强化广泛使用的沙箱技术，从而提升众多应用的防护水平。 ## 帮助我们改进这一方法 我们分享这一方法，是希望维护者、研究者、响应团队、服务商和运维人员能够帮助使其具备可操作性。我们希望了解它在哪些场景中有帮助、哪些场景可能增加延迟或负担，以及我们遗漏了哪些方面。来自过去披露案例的实例将特别有价值。 我们尤其关注以下方面： - **披露时间窗口。** 维护者、运维人员和防御者需要多长时间来准备和部署可靠的修复方案？什么样的证据应该触发更早的披露，特别是在部分用户可以比其他用户更早获得保护的情况下？ - **紧急补丁。** 政府或其他运维人员在失去管理权限后，是否应该、以及在什么情况下使用漏洞信息来修补其拥有或获授权管理的系统？应适用哪些安全保障措施？我们可以设想这样一种终极状态：互联网范围的持续性扫描已知漏洞，一旦检测到就通知网站所有者或直接修补系统。 - **提前通知。** 谁需要提前获得通知以采取有用的防护措施，包括我们可能遗漏的防御者？分阶段通知在什么情况下比一次性通知更大范围的人群更有效？我们应该如何在覆盖范围和泄露风险之间进行权衡？ - **默认安全的软件包。** 在上游修复尚待发布期间，我们如何帮助识别和修复下游包中的漏洞？或者将修复回移到不再接收安全更新的旧版本？什么样的测试和维护可以确保这些包在无法及时升级时成为可靠的替代选项？ 我们同样欢迎对独立安全专家的推荐，他们可以审查这一方法、挑战其假设并识别遗漏之处。您的反馈将帮助我们完善响应流程并确定支持的优先级。[在此分享您的反馈](https://docs.google.com/forms/d/e/1FAIpQLSfcynrrWRWdj0PLAwtwVg2pfr0IvyAx5HfRBYf5tZin1AMLiQ/viewform)。