AREX Feed Article
OpenAI 公布『Defense Factory』：称动员 250 余人强化数百系统防御，公开架构与实操手册
OpenAI 于北京时间 9 月 10 日凌晨通过官方 X 账号公布其『Defense Factory』防御体系的建设成果（）：称在一场“安全冲刺”（security sprint）中动员了 250 多人，在数百个系统上加强防御；其最新 cyber（网络攻防）模型“帮助我们发现并修复了若不借助它们、或许永远不会发现的漏洞”。官方同时表示，把这次行动的经验总结、所用架构和一份实用 playbook（实操手册）一并公开，供外界搭建自己的 Defense Factory——一个由 AI 智能体发现漏洞、验证漏洞、并核实修复确实生效的持续闭环。
上述动员人数、系统规模与漏洞发现修复效果，均出自 OpenAI 官方口径。推文短链指向的给出了过程细节：OpenAI 称，随着新模型能力允许它更深入地审视自身系统，公司在内部拉响“code red”，把安全（Security）、应用（Applied）与研究（Research）团队集结进一次横跨数百个系统、覆盖 100 多个服务领域的协同冲刺。
一场按事故响应标准组织的冲刺
Thibault Sottiaux（OpenAI 核心产品与平台负责人，Head of Core Products & Platform）在发布页上为这次冲刺定调：“我们正以处理事故的紧迫性加强防御。这是一场全员行动，优先级仅次于关键业务运营。冲刺结束后，我们也会带着同样的紧迫性继续测试和强化防御。”
冲刺的实际运作以 Codex 为主力：页面称补丁生成 100% 由 Codex 完成，团队在系统清点和所有权模型尚未建全时就开始处理积压问题，第一天便关闭了 53 个紧急或高优先级问题；Codex 同时协助建立资产清单，把服务与负责人信息整理成可复用输入。页面还写道，这次冲刺只是 Defense Factory 的起点，OpenAI“正朝着持续防御闭环推进——绘制系统地图、发现并验证漏洞、指派负责人、核实修复，并在每一轮运行中改进系统”。
五步闭环：从清点系统到复核已部署的修复
按 OpenAI 的定义，Defense Factory 是一套以智能体为先、持续运转的自动化防御作业，用于不断发现、验证并修复漏洞。智能体沿用现有安全与工程工具，按可复用技能（skills）执行工作流，在隔离、用完即弃的复现环境里调查发现并测试补丁。页面把闭环拆成五步：清点（inventory，映射并关联系统）、发现（discovery，扫描、分析、导入）、动态验证（dynamic validation，复现并确认）、所有权指派（ownership assignment，定位负责团队）、核实修复（verified remediation，修复部署后独立复测）。每一步都复用上一轮留下的系统地图、负责人信息与证据，只把精力留给变化和未解决的风险；有重大影响的改动仍由人审核。
支撑这套流程的基础设施也在页面上公开：系统整体分为控制面与数据面——控制面承担工作负载编排、策略执行与凭据代理，数据面是带开发容器、环境身份与宿主监控的开发环境；安全与审计组件横跨两侧，覆盖主机活动、基础设施安全与智能体审计。智能体一侧的工具是 Codex Desktop、Codex CLI 与 Codex Security CLI，配合安全扫描、发现分级、修复发现等预置技能；模型一侧，页面列出了 Astra、Sol、Terra、Luna 等通用模型，以及 Daybreak Blue、Daybreak Red 两个安全模型入口。传统工具链（GitHub 或 GitLab、Snyk 与 Semgrep 等扫描器、Jira 或 Linear 等工单系统）经 MCP（模型上下文协议）、CLI 或 API 接入。
页面给出的对照表说明这套体系补在传统安全流程的哪些断点上：发现之后自动触发调查、重复报告自动合并并测试可利用性、每个发现都指派到明确负责人、工程师拿到带证据的已测试补丁。页面还称，Cloudflare、Ramp 与 Google 的团队也在探索类似做法。
官方数字与页面自带的限定
页面公开了几组过程指标：服务与负责人信息可复用后，被接受的所有权指派比例达到 90.6%；经过去重改进，37% 的发现被判定为重复问题；动态验证在少数可反复运行的服务上展开后，19.5% 的发现能在运行环境中复现，误报率降到 0.81%；智能体生成的修复被回滚的比例为 0.53%。
这些数字附带过程经验：环境搭建一度成为验证瓶颈，团队补齐缺失依赖与配置差异后，才分得清“发现无法复现”和“测试本身跑不起来”；早期严重度标签过宽、结果随指令变化，团队把分级标准与提示词版本化，加入可重复评估和人工抽查；跟进检查暴露出“代码已合并”与“修复已部署到全集群”之间的落差后，团队扩大了验证范围、在确认修复后留言，同时暂不开启自动重开工单，直到能妥当处理部署延迟。
这些数字的边界，OpenAI 自己也写在页面上：多张示意图旁注明“这些是示意轨迹，不是测量结果，也不是预测”；冲刺成果图表旁的说明则写道，报告被标记为完成或已解决，但“记录在案的完成，并不构成独立核实的已部署修复”。
机器速度的攻击与收窄的『防御者窗口』
Defense Factory 的出发点，是 OpenAI 对攻击侧的判断：越来越多可获取的开源权重模型（open-weight models），让智能体能够执行长时间、机器速度的网络攻击。页面写道，成队运行的长时智能体能在大规模系统上利用弱点，“远早于人在回路中的安全响应发现并修补同样的漏洞”。页面称，防御方有两个结构性优势：给智能体直接访问自家代码的权限，并用前沿模型抢在“滥用广泛流传的开源权重模型的攻击者”前面。页面把这段领先时间称为“防御者窗口”，并称窗口正在收窄。
Defense Factory 公布前的 8 月，OpenAI 已发布两篇相关材料。8 月 10 日，OpenAI 在中宣布扩展其 Daybreak 网络安全项目：设置 Daybreak Blue 与 Daybreak Red 两个准入级别，前者向获准的防御方开放带相应防护的前沿通用模型，后者提供专用攻防模型；同时推出专为网络攻防训练的 GPT-5.6-Cyber。8 月 17 日，Greg Brockman 在中称，7 月发生的 OpenAI-Hugging Face 事件表明“我们低估了自家 AI 模型在现实世界中的网络能力”，并称各组织需要现在就行动，在未来数月内把安全项目大幅自动化。Defense Factory 页面上列出的安全模型同样以 Daybreak 命名，申请入口也指向 Daybreak 项目。
给外界的材料：简报、Daybreak 申请与 Codex Security
面向想自建 Defense Factory 的组织，页面给出三个入口：briefing deck（介绍简报），供向团队说明理由、确定方向并约定第一个工作流；Daybreak 申请通道，面向“获授权的防御工作”开放高级 cyber 模型的使用资格；Codex Security 插件，用预置技能去发现漏洞、验证发现并准备修复。已经是 OpenAI 客户的组织，可以直接与客户团队讨论架构。
页面同时预告了下一步：更详细的技术博客文章（technical blog post）“即将发布”，但没有给出时间。