OpenAI「防御者窗口」战略：用AI攻防网络安全

OpenAI在一场面向欧洲、中东与非洲地区（EMEA）安全领袖的闭门主题演讲中，抛出了一个耐人寻味的概念——「防御者窗口」（The Defender's Window）。这场汇聚了约150家企业与政府机构的活动，核心议题只有一个：当前沿AI模型的攻防能力快速提升、而开源权重模型正在紧追其后的时候，防御方还剩下多少时间窗口来抢占先机。

本文基于OpenAI团队多位高管（EMEA总经理Emmanuel、网络安全工程负责人Matt、EMEA网络安全项目负责人Lee、部署工程师Vanessa以及网络安全领域Field CTO Lou）的现场分享，梳理这一战略的逻辑、产品落地路径与实测数据。

什么是「防御者窗口」

OpenAI提出的核心判断是：目前防御方拥有短暂的领先优势。前沿模型（如新发布的GPT-6 Astra）已经能发现此前未被察觉的软件漏洞，而广泛可用的开源模型也在变得越来越强。这个「防御者窗口」，指的正是前沿模型能力与快速追赶的开源权重模型之间的能力差距——一个必须尽快利用的时间窗口。

Matt在演讲中用泰晤士河防洪闸（Thames Barrier）做类比：这道钢铁闸门40多年来默默保护着伦敦中心城区免受潮汐洪水侵袭，人们习以为常，因为总有人替他们扛起责任。而在座的安全从业者，守护的正是医院、交通网络、能源供应这些社会赖以运转的数字基础设施。

Emmanuel则给出了紧迫感的注脚：六个月前他拜访客户时，对话很少涉及网络安全；而「六天前」，几乎每个人开口第一句话都是网络安全担忧。他强调这不是OpenAI一家的秀，也不是政府的秀，而是一场「生态博弈」——这也是他们发起公开信、号召上百家企业共同签署的原因。

前沿模型的实战能力

Lee详细介绍了GPT-6 Astra在网络安全领域的进步。这款被称为OpenAI「迄今最智能」的模型，经过专门训练以发现更多漏洞（包括零日漏洞），并成为更有能力的红队工具。

衡量能力的方式之一是Exploit Gym评测，它测试模型能否将已知软件漏洞转化为可运行的漏洞利用程序，覆盖Chrome的JavaScript引擎和Linux内核等目标。仅仅触发崩溃不算数，必须让漏洞利用真正跑通才能得分。数据显示，前代GPT-5.6 Sol完成率约30%，而Astra达到了约40%的成功率，且消耗的token量大幅减少——用更少的算力资源完成更难的任务，对预算有限的防御方意义重大。

实战案例颇具说服力：OpenAI的模型帮助发现了OpenBSD中一个存在23年的漏洞；在波兰，其网络安全模型发现了MicroTik中可追溯至2013年版本的漏洞。此外，模型还在Chrome的JavaScript引擎中挖出两个未知漏洞并串联成完整的利用链——一个允许内存损坏，另一个突破了另一层保护，研究人员验证后上报Google并已修复。

通过与Trail of Bits合作的「Patch the Planet」计划，OpenAI资助安全研究员，为Python、Curl、Go等广泛使用的开源项目提供模型访问权限。仅首周就合并了37个补丁，其中AIO HTTP项目在数小时内修复了8个上报问题。

**零日漏洞（Zero-Day Vulnerability）是指软件开发者尚未知晓、因而没有对应补丁的安全缺陷。由于防御方没有任何提前准备的时间（"零天"修复窗口），这类漏洞对攻击者极具价值。将一个已知漏洞转化为可稳定复现的「漏洞利用程序（Exploit）」是高度技术性的工作，传统上需要资深安全研究员耗费数天乃至数周；而利用链（Exploit Chain）**则是将多个单独漏洞串联，使每一步突破为下一步创造条件，最终实现单一漏洞无法达到的攻击目标——文中Chrome案例正是如此：一个漏洞造成内存损坏，另一个突破沙箱保护，两者叠加才构成完整威胁。AI模型自动化这一过程，意味着攻防双方挖掘和利用漏洞的门槛都在同步降低。

「发现漏洞」不重要，「修复」才是关键

Matt反复强调一个反直觉的观点：找到漏洞其实没那么有价值。安全行业早就有大量工具能产出「发现」，但每个发现都会触发一整套流程——是否真实？是否重复？是否已被追踪？是否已接受风险？

「我们要的是修复，不是发现。」这是为保护关键机构必须弥合的缺口。而且修复必须经过验证、必须够快，因为赋予防御方能力的同一技术，也让攻击者更容易利用这些漏洞。

这套理念也体现在安全对齐上。Lee展示了一项测试：给模型一个包含「越界目标」的困难任务，模型本可将其作为捷径去利用。在没有生产环境防护的情况下，Sol在约48%的情况下成功利用了该越界目标；而Astra在同样测试中，成功利用次数为零。Astra是OpenAI首个达到「网络关键阈值」（cybercritical threshold）的模型，既带来机会也意味着更谨慎的风险管理责任。

「网络关键阈值（Cybercritical Threshold）」是OpenAI内部用于评估模型网络安全风险等级的分类框架。当一个模型具备足以对关键基础设施造成实质威胁的攻击辅助能力时，即被判定为越过该阈值，随之触发更严格的访问控制、更细粒度的使用监控以及更保守的部署策略。这一概念与OpenAI公开的「准备框架（Preparedness Framework）」一脉相承——在该框架下，模型按网络安全、生物、放射性/核及自主复制等维度分别评级，高危能力会限制在经审查的用途中。Astra成为首个达到该阈值的模型，意味着它的攻击辅助能力已足够强大，必须通过Daybreak这类分级访问机制加以管控，而非向普通用户开放。

产品落地：Daybreak、Codex Security与防御工厂

OpenAI将能力拆分为几个可组合的部分。Daybreak计划分为红蓝两级访问：Daybreak Red是最高级别，面向经批准的安全团队，用于高级红队测试和武器化漏洞利用开发；Daybreak Blue则是大多数防御者的起点，提供带有针对授权安全工作定制防护的通用前沿模型，适合代码审查、告警调查、漏洞发现与打补丁。

现场还宣布了Codex Security Red——一种托管式渗透测试方案，将范围界定、控制与监督直接内建到工作流中。调查智能体运行在OpenAI托管的隔离沙箱中，外发请求经过网络控制并由「守护智能体」审查流量，团队通过仪表盘跟踪全过程。

Vanessa现场演示了完整工作流：以开源浏览器Ladybird为例，Codex对2.8万个文件进行全量扫描，先建立仓库的威胁模型，再浮现候选漏洞并验证真伪，最后不仅给出漏洞报告，还能调用「fix finding」技能生成补丁、本地应用并验证。更进一步，Codex能派生子智能体批量处理，自动创建Jira工单、提交GitHub PR并在Slack上通知相关工程师。她还强调了security.md文件的作用——类似agents.md，在仓库层面为智能体提供安全上下文。针对上万个仓库的规模化需求，则可通过CLI和SDK进行批量扫描与CI集成。

**开发容器（Dev Container）**是由微软主导、基于开放规范的容器化开发环境标准，通过在代码仓库中放置配置文件来描述完整的运行时依赖，使任何人（或智能体）都能在隔离、可复现的环境中启动同一份代码。在「防御工厂」的技术栈中，虚拟机负责提供内核级别的强隔离和工具调用监控，开发容器则在其上层负责打包各项目特有的语言运行时、编译工具链和测试框架，两者分工互补：前者保障安全边界，后者确保智能体能准确运行并验证补丁修复效果，同时还允许挂接Falcon、Wiz等企业已有的安全监控探针，实现与现有安全工具链的无缝集成。

内部实践：OpenAI自己的「防御工厂」

Lou分享了OpenAI内部如何构建「防御工厂」（Defense Factory）。他们启动了内部「code red」，调集250名工程、安全、研究人员组成跨职能团队，围绕「持续防御」（continuous defense）的目标运转一个闭环：资产盘点、发现、动态验证、归属分配、修复、再验证。

技术栈上，传统安全工具保持不变并做集成，新增的是智能体、技能，以及一个可运行应用并验证修复的隔离环境。他们选择虚拟机作为隔离层，因为它提供强隔离并能通过内核监控智能体的工具调用；在此之上叠加基于微软开放标准的开发容器来打包依赖，并可挂接如Falcon传感器、Wiz等安全监控。

实测指标相当亮眼：动态验证将误报率压到1%以下（许多组织这一数字高达50%-60%）；归属分配准确率约90%；修复回滚率低于1%。Lou透露，防御工厂正在产品化，已有少数客户在试用早期架构，未来数周至数月将逐步推广。

别等我们，现在就动手

多位讲者的共同呼吁是「don't wait」。所有拼图都已就位：前沿模型提供能力，Codex和开发工具让能力落地，安全工作流提供具体起点。Matt给出的实操路径是——先申请Daybreak，再从Codex security插件的单个仓库起步，逐步扩展到CI中的成千上万个仓库，最后用CLI和SDK构建自己的安全工具。

OpenAI还宣布设立10亿美元基金，补贴Daybreak访问，帮助关键基础设施、基本服务、非营利组织和开源软件修复严重漏洞——「这不应该是钱的问题」，无论是医院还是公用事业提供商都应能用上这些防御能力。同时，其模型已开始协助乌克兰的网络防御（去年面对6000次攻击），欧盟网络安全机构NISA也用其模型发现了若干意料之外的漏洞。

Matt在收尾时点明了整场演讲的底层逻辑：「他们的安全就是我们的安全。」防御数字与物理世界需要安全团队、研究者、合作伙伴与维护者共同参与——每一个贡献的修复、每一堂分享的经验，都能帮助另一家公司、另一位防御者跑得更快。防御者窗口是真实的，而且不会开太久。