返回 文章 apply CMS 文章

OpenAI 联合多方修复 PHP 关键漏洞,提出 AI 时代全球漏洞响应框架

前沿 AI 先于攻击者发现 PHP 关键漏洞,OpenAI 借此提出一套可复用的全球漏洞协调响应框架。

OpenAIPHP漏洞漏洞响应开源安全
成长分 / 100 73 综合收获、行动、留存与影响

OpenAI 联合多方修复 PHP 关键漏洞,提出 AI 时代全球漏洞响应框架
为什么值得读了解前沿 AI 模型在真实开源软件中发现关键漏洞的案例及其对攻防平衡的影响

掌握 OpenAI 提出的五阶段漏洞协调响应流程,可作为组织应急响应的参考

关键洞察
  1. OpenAI 使用 GPT‑5.6 Sol 在 Patch the Planet 计划中发现 PHP 关键漏洞,Wiz 也独立发现并报告了这两个漏洞
  2. PHP 维护者主导修复与发布,OpenAI、Wiz、Cloudflare 等提供研究、技术支持与协调,在披露前准备防护措施
  3. OpenAI 认为这是近年影响最大的安全问题之一,并称前沿 AI 先于攻击者发现漏洞,形成“防御者窗口”
转成行动

深入阅读

正文与原文对照

原文保真覆盖:全文原文字符:13234

过去两个月里,我们牵头了一个由维护者、研究人员和安全提供商组成的联盟,以解决 PHP 中的严重漏洞,PHP 是一种用于运行网站和 Web 应用的开源编程语言。作为我们 Patch the Planet⁠ 计划的一部分,Calif 使用 GPT‑5.6 Sol 识别出一个严重缺陷,Wiz 也独立发现并报告了这两个漏洞。PHP 的维护者主导了修复和发布,我们的团队以及 Wiz、Cloudflare 等合作伙伴贡献了研究、技术支持和协调,以便在披露前准备好防护措施。

对于使用 PHP 的组织,现在的优先事项是应用修复。 我们正在分享一个 PHP 版本检查器作为 Codex 技能⁠,以帮助运维人员识别可能存在漏洞的 PHP 版本,并结合 PHP 及其提供商的指导,确定哪些更新适用。

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

据我们所知,前沿 AI 在攻击者之前发现了这些漏洞,为维护者和安全提供商打开了一个 Defender’s Window,以便在披露前准备修复和防护。

为了帮助更多防御者使用这些能力,我们承诺通过 Daybreak for Frontline Defenders 提供 10 亿美元的补贴 Daybreak access,重点关注保护基本服务但安全资源有限的组织。

尽管这些漏洞很重要,但它们只是我们已经发现并正在努力修复的几个重要漏洞之一,我们预计未来几个月类似的发现将急剧增加。根据我们迄今为止的经验,我们正在分享一种适合 AI 时代的方法,用于应对广泛使用的软件中的严重漏洞,并请求安全社区帮助改进这一框架。它汇集了我们的模型、安全专业知识和维护者,帮助将发现转化为防护,并构建一个随着 AI 能力进步而可扩展的响应。

协调全球响应

让修复投入使用可能意味着为旧版本进行调整、准备提供商缓解措施以及更新许多组织的系统。可重复的流程有助于这些团队在发现更多漏洞时快速行动。

通过 Patch the Planet,我们贡献了安全专业知识和模型访问权限来支持 PHP 响应,并与维护者和研究合作伙伴合作测试修复并准备指导。我们还帮助协调基础设施提供商为受影响系统提供防护,并联系政府网络机构,帮助指导到达关键组织。这支持了维护者主导的响应,并帮助其他防御者做好准备。

对于某些发现,研究人员可以直接与软件的维护者合作调查问题并开发修复。其他发现需要更广泛的响应,因为它们影响许多产品,或者因为分销商和服务提供商需要时间(如果前沿能力并不比广泛可用的能力领先太多,时间可能很短缺)来准备更新和防护。在这些情况下,提议的框架可以帮助维护者确定需要涉及谁并协调工作。响应可能涉及五个阶段:

  • 验证并修复上游漏洞。 维护者、研究人员和必要的技术合作伙伴确认发现,评估其影响,并开发和测试修复。此过程包括使用前沿模型进行对抗性测试,以寻找绕过补丁的方法以及漏洞的相关变体。
  • 给受影响组织时间采取行动。 我们提出了一个框架,用于考虑哪些组织需要预先信息来准备防护,同时维护者决定涉及谁。我们帮助进行外联、信息共享协议以及团队之间的协调。分销商可能为旧版本调整修复,托管提供商可能测试缓解措施,安全提供商可能准备检测或预防措施,包括 Web 应用防火墙(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 可以帮助工程师测试和加强广泛使用的沙箱技术,改善许多应用程序的保护。

帮助我们改进这种方法

我们分享我们的方法,以便维护者、研究人员、响应团队、提供商和运维人员可以帮助使其可行。我们想了解它在哪些方面有帮助、在哪些方面可能增加延迟或负担,以及我们遗漏了什么。过去披露的示例将特别有用。

我们特别感兴趣的是:

  • 披露窗口。 维护者、运维人员和防御者需要多少时间来准备和部署可靠的修复?什么证据应触发更早的披露,特别是当一些用户可以比其他人更早受到保护时?
  • 紧急打补丁。 政府或其他运维人员何时(如果有的话)应在失去管理访问权限后使用漏洞为他们拥有或授权管理的系统打补丁?应适用哪些保障措施?我们可以想象一个最终状态:互联网范围内始终在线的已知漏洞扫描,并在检测到漏洞时通知站点所有者或为系统打补丁。
  • 提前通知。 谁需要提前警告才能采取有用的保护行动,包括我们可能遗漏的防御者?分阶段通知何时比一次性通知更广泛的群体效果更好,我们应如何权衡覆盖范围与泄露风险?
  • 默认安全的软件包。 我们如何帮助识别和修复下游软件包中的漏洞,同时上游修复仍在进行中,或将修复向后移植到不再接收安全更新的旧版本?当及时升级不可行时,哪些测试和维护能使这些软件包成为可靠的选择?

我们也欢迎推荐能够审查该方法、质疑其假设并找出差距的独立安全专家。您的意见将帮助我们完善响应并确定支持的优先顺序。在此分享您的反馈⁠。