Codex Security Cloud：四阶段流水线及其边界
Codex Security Cloud 如何扫描 GitHub 仓库：威胁模型、验证沙箱、修复流程，以及 OpenAI 自己声明的各项限制。
Agent Skills
Codex Security Cloud 是 OpenAI 的应用安全智能体，它会扫描已连接的 GitHub 仓库、验证可能的漏洞，并返回带证据和修复建议的发现项。它是 Codex cloud 的一个插件，可在网页端和桌面应用中使用；2026 年 9 月 29 日的 DevDay 升级新增了两项能力，改变了团队使用它的方式：对新提交进行持续审查，以及默认包含通过 Daybreak Blue 提供的具备网络攻防能力的模型，无需另行申请 Daybreak Blue。
OpenAI 自家文档中最重要的一句话是一条限制，而非一项功能：Codex Security 是对 SAST 的补充，而不是替代，它也不替代人工安全审查。第二重要的是一句成熟度提醒：文档把 Codex Security Cloud 称为研究预览（research preview），而 DevDay 回顾则把它列为已在桌面端和网页端向 Pro、Business、Enterprise 和 Edu 提供。这两句话都出自 OpenAI。本指南在两者分歧之处采用更严格的解读，并说明在哪里分歧。
Codex Security Cloud 是什么，又不是什么
OpenAI 交付了三样相关但不同的东西，把它们混为一谈是这次发布中最常见的困惑来源。
Codex Security Cloud 是本文要讲的插件。它在 Codex cloud 中扫描已连接的 GitHub 仓库，运行于网页端和桌面应用，既支持一次性仓库扫描，也支持对新提交的持续监控。
Codex Security 插件 是另一个用于本地工作的插件。它在 Codex 任务中、在桌面应用或 CLI 里扫描本地仓库，也是产出带有 Scans、Findings 和 Repositories 视图的工作台的那一个。OpenAI 的文档明确说明两者不是同一个插件。
CLI 与 TypeScript SDK 以公开的 @openai/codex-security 包形式提供。CLI 可以发现 GitHub 仓库、恢复批量扫描、跨扫描追踪发现项、记录误报反馈，并在 CI 中或提交前运行检查，支持 SARIF 上传和严重性策略。SDK 则让你把扫描、进度上报和成本控制构建进自己的工具。
对云产品而言，所需输入很窄，值得先列出来：一个拥有 Codex Security Cloud 访问权限的工作区、一个已连接的 GitHub 仓库，以及一个兼容的 Codex cloud 环境。后两项都可以在首次扫描期间设置好。
四阶段流水线
OpenAI 用四个有名字的阶段来描述分析流水线。弄清某个结果出自哪个阶段很重要，因为各阶段的失败模式不同。
| 阶段 | 做什么 | 产出什么 | 可能在哪里失败 |
|---|---|---|---|
| 1. 分析（Analysis） | 为仓库构建威胁模型：对代码工作方式、入口点与不可信输入、信任边界与鉴权假设、敏感数据路径，以及团队希望优先审查区域的简要概括 | 指导后续一切的扫描期安全上下文 | 错误或过时的威胁模型会把整个扫描带偏；它由代码生成，并且正因如此才可编辑 |
| 2. 扫描（Scanning） | 一次性审查仓库，或对提交变更进行监控以查找可能的问题 | 候选发现项 | 不保证覆盖率；OpenAI 称其表现取决于模型对所使用语言与框架的推理能力 |
| 3. 验证（Validation） | 尝试在隔离容器中复现每个可能的问题 | 已验证或未验证状态，外加日志、命令和产物作为证据 | 验证可能失败，发现项保持未验证；日志仍会记录尝试过的内容 |
| 4. 修复（Remediation） | 提供建议，并在可行时给出待审查的补丁建议，供你在开 PR 之前审阅 | 带严重性的排序发现项、修复建议，以及带文件名和行上下文的建议最小差异 | 补丁只是建议；不会自动应用或推送任何东西 |
OpenAI 所宣传的「去重」发生在第二阶段和第三阶段之间。这个机制的准确说法值得讲清，因为「对发现项去重」听起来比实际更巧妙：模型先对可能的问题排序，随后自动验证尝试在干净容器中复现每一个，成功复现的发现项被标记为已验证。这种两阶段结构是为了在人类阅读之前减少误报，而不是为了证明某个发现项在你的环境中确实可被利用。
设置步骤
OpenAI 记录的设置路径短到可以在此完整复现。
- 在网页端或桌面应用的 ChatGPT 中打开 Plugins，在市场中搜索 Codex Security Cloud，安装并启用它，然后从已安装插件或侧边栏打开 Security Cloud。如果无法访问，文档建议与你的工作区管理员确认。
- 确认工作区已设置好 Codex cloud。在插件中选择 New scan。若被提示，选择 Connect GitHub 并授予对你想扫描仓库的访问权限。仓库未出现在列表中，意味着它的 GitHub 连接或权限需要检查。
- 启动仓库扫描：选择仓库，选择一个兼容的 Cloud environment，或选择 Create environment 来配置一个，把 What to scan 保持为 Repository（默认值），然后选择 Start scan。
- 在 Scans 中打开该扫描以跟踪进度，然后打开 Findings 并选择一个问题，审查受影响的代码、验证证据和修复建议。当某项发现提供 Fix with Codex 时，选择它以生成建议补丁，审查该补丁，之后才选择 Create draft pull request。
持续监控是另一种模式：New scan，选择仓库和 cloud environment，把 What to scan 设为 Commit changes，然后选择 Create。之后在 Repositories → Monitoring settings 中更改 cloud environment、选择要审查多少天的历史，以及暂停或启用监控。保存即应用更改。
文档指出，cloud environment 可以在扫描设置期间创建，而不必提前准备，这消除了首次扫描卡住最常见的原因。
威胁模型是你自己要把关的部分
如果说这次发布中有一个值得养成的操作习惯，那就是编辑威胁模型。它也是最容易被跳过的一步，因为首次生成的版本看起来已经够用。
OpenAI 自己对「有用威胁模型」的描述点名了四件事：入口点与不可信输入、信任边界与鉴权假设、敏感数据路径与特权操作，以及团队希望优先审查的区域。文档中给出一个示例：某服务对外暴露用于账户变更的公开 API，接受 JSON 请求和文件上传，通过内部鉴权服务校验身份，并通过内部服务写入账单变更。这个示例中的指示才是可操作的部分：把审查重点放在鉴权检查、上传解析，以及服务间信任边界上。
这个示例就是「必须编辑」的全部理由。没有它，扫描器只能去猜一百条代码路径里哪些是你团队认为承载关键逻辑的。有了它，扫描就会优先处理你点名的地方。编辑路径是 Repositories → 选择被监控的仓库 → Monitoring settings → Project context → 编辑 Threat model → Save，更改将应用于未来的扫描。
威胁模型有两个属性值得内化。它由仓库代码生成，因此概括的是架构与安全入口点，而非业务上下文——业务上下文要由你来补充。它被用来指导未来的提交扫描并给发现项排序，这意味着过时的威胁模型不只是带偏一次扫描；它会持续带偏之后的每一次扫描。
客户代码如何被隔离
隔离模型是安全团队首先会问的部分，而 OpenAI 的回答很具体。
每个分析和验证作业都在一个临时（ephemeral）的 Codex 容器中运行，使用会话作用域的工具。产物会被提取出来供审查，作业完成后容器即被销毁。目标仓库会被临时克隆以供分析。验证在沙箱内运行命令或测试，并把结果作为证据附上。
扫描器无需编译步骤即可从仓库和提交上下文产出发现项。但在自动验证期间，如果有助于复现问题，它可能会尝试在容器内构建项目——这意味着要让验证阶段运作良好，环境需要具备构建你项目的能力。
由此带来一个重要的局限。因为验证依赖在容器中复现问题，那些需要活跃服务、特定数据状态或异常网络访问的代码中的发现项可能保持未验证。OpenAI 说明了此时会发生什么：发现项保持未验证，日志和报告记录下尝试过的内容，以便工程师重试或调整复现步骤。未验证的发现项既不是误报，也不是已确认的漏洞。
扫描会产出什么
完成的扫描既产出人类可读的入口点，也产出机器可读的数据，这正是让输出可用于流水线、而不只是用于 UI 的原因。
report.md—— 扫描结果的主要可读入口。findings/<slug>/—— 详细的漏洞报告与支撑性概念验证文件（如有）。hardening/—— 结构性加固建议，附支撑性方案或图示（如有）。scan-manifest.json、findings.json和coverage.json—— 供自动化与集成使用的结构化扫描数据。
OpenAI 建议在分享或归档结果时保持整个扫描目录完整，这是务实而非美观的考量：report.md 内部的链接指向同级文件，因此孤立的 report.md 是一份坏掉的文档。
修复产物同样具体。当某个发现项能生成修复方案时，建议补丁包含带文件名与行上下文的最小可执行差异。该工作流会生成 diff、补丁文件或建议改动，供维护者和审查者在应用前检查，它不会直接修改你的 PR 分支。
OpenAI 说自己在哪里停下
OpenAI 自家文档中出现了三条限制，说得直白，它们应当是你向安全团队作任何承诺之前最先读到的内容。
它不是 SAST 的替代品。 Codex Security 是对 SAST 的补充。它增加了基于模型的语义推理和自动验证，而现有 SAST 工具仍然提供广泛的确定性覆盖。这句话几乎就是精确的分工：确定性工具负责广度与已知规则覆盖，推理智能体负责规则无法表达的 bug 类别，验证负责过滤噪音。
它不是人工审查的替代品。 它加速审查、帮助给发现项排序，但不替代代码级验证、可利用性检查或人工威胁评估。
覆盖率取决于语言和框架。 Codex Security 在设计上语言无关，但 OpenAI 明确表示，实践中表现取决于模型对仓库所使用语言与框架的推理能力。因此，一个使用不常见技术栈的 monorepo 与一个主流仓库是完全不同的命题，诚实的规划假设应是：覆盖率随仓库而异，而非一律相同。
对所有计划试点的人来说，还有一个访问前提：运行扫描需要 Codex Security 访问权限，OpenAI 建议使用一个经过其网络项目验证的账户以获得最佳效果。如果无法访问，文档给出的路径是与你的工作区管理员确认，而不是假定功能坏了。
这些说法如何分级
由于产品处于研究预览阶段，诚实的切分是在「OpenAI 文档所述的设计行为」与「今天可测量的东西」之间。下表把这层切分显式化。
| 说法 | 分级 | 证据与细节说明 |
|---|---|---|
| Codex Security Cloud 扫描已连接的 GitHub 仓库并监控新提交 | 依据产品文档验证 | 设置与监控路径均逐步记录；Repository 与 Commit changes 两种模式都有描述 |
| 四阶段流水线：分析、扫描、验证、修复 | 厂商声明 | 在 OpenAI 自家 FAQ 中被命名并描述；无独立重建 |
| 验证通过在沙箱中复现问题来减少误报 | 厂商声明 | 机制有描述；未公布验证前后的误报率 |
| 每个作业在临时容器中运行，之后被销毁 | 厂商声明，设计层面 | FAQ 中有描述；无法从外部独立核验 |
| 建议补丁在创建任何 PR 之前先被审查 | 依据文档验证 | 工作流生成 diff 或补丁，且从不直接修改 PR 分支 |
| 它补充 SAST，而非替代它 | 厂商声明 | OpenAI 自家的范围声明；属于保守解读，应向利益相关方引用 |
| 它不替代人工安全审查 | 厂商声明 | OpenAI 自家的范围声明 |
| 覆盖率随语言和框架变化 | 厂商声明 | 设计上「语言无关」，表现取决于模型推理能力 |
| 向 Pro、Business、Enterprise 和 Edu 提供 | 在 DevDay 回顾中验证 | 文档称其为研究预览，在成熟度表述上与之相左；两者都被陈述 |
| Daybreak Blue 的具备网络攻防能力的模型默认包含 | 在回顾与发布帖中验证 | 未公布独立的 Daybreak Blue 页面或模型清单 |
| 准确率、召回率或误报率 | 未公布 | 在核对的每个一手来源中均缺失；资料来源中不存在独立评估 |
最后一行正是下文试点计划存在的原因。一个没有公布准确率数字的安全工具，应当先在你自己的仓库上评估，再被信任于整个代码库。
这如何改变安全类技能的工作流
如果你维护用于安全工作的智能体技能，这次发布改变的是人力投入的流向，而不是消除它。有三处变化值得提前规划。
分诊成为瓶颈。 一个产出带证据的、已验证或未验证的排序发现项的扫描器，把困难的工作从「找 bug」转移到「判断哪些才重要」。为这种判断打造的注册表条目是 security-best-practices，对应那些在代码库中被修复之前扫描器会反复报告的代码级规则；以及 threat-mitigation-mapping，对应你现在要在 Monitoring settings 中手工维护的映射步骤。
你的威胁模型成为一份需维护的产物。 它不是一项扫描设置，而是一份带有运维后果的文档。如果你的团队已经在写架构决策记录（ADR），威胁模型就是这一实践在安全侧的对应物，它需要一个负责人。
验证改变了审查契约。 标记为已验证的发现项附带着复现证据。未验证的发现项则记录着尝试过的内容。这是两种不同的审查任务；把它们一视同仁的工作流，要么会过度信任输出，要么会过度忽视输出。带着这种上下文审查改动的注册表条目是 differential-review，而 api-security-best-practices 是威胁模型应当点名的服务间信任边界的相关页面。
要与仓库扫描一起扫描依赖类发现项的积压，最接近的注册表对应项是工具替代类合集 snyk 与 dependabot。更广泛的技能集合位于安全分类和 security-audit 标签之下。
一个能产出数字的试点计划
已公布材料中不含 Codex Security Cloud 的准确率数字，资料来源中也不存在独立评估。这一缺失正是要做试点、而不是凭信任采用的理由；而试点成本很低，因为该工具是一个插件，而非一个集成项目。
挑选两个有已知历史的仓库。 其中一个应当包含你最近已发布的安全修复，以便检查扫描器当初是否会发现它。另一个应当是你认为代码干净的仓库，用以测量噪音。
在首次扫描前编辑威胁模型。 先扫描，再把发现项与已知修复对比。一个漏掉了你已修复 bug 的扫描器，比一百个价值未知的发现项能告诉你更多关于这个工具的信息。
在第一轮把已验证与未验证的发现项分开。 分别计数，并抵制把它们平均的诱惑。已验证集合是工具愿意为之背书的部分；未验证集合是一列等待人工判断的队列。
衡量已验证发现项的命中率，而不是发现项数量。 有用的比率是「工程师认可为真实的已验证发现项 ÷ 已验证发现项」。除此之外的任何口径都是在奖励扫描器的啰嗦。
在两个仓库上试点就停下。 在拿到这个比率之前就扩大范围，等于把一个未知错误率乘以你的整个代码库。只有当单仓库数字稳定，并且你已经确定由谁来分诊队列之后，才扩大范围。
可用性、套餐与 Daybreak Blue 之问
DevDay 给出的可用性表述是：Codex Security Cloud 已在桌面端和网页端向 Pro、Business、Enterprise 和 Edu 提供。产品文档则把它描述为在网页端和桌面应用中以研究预览形式提供。DevDay 帖子还补充了一条运维说法：笔记本合上时它也能工作，这是在 Codex cloud 中运行而非本地运行的必然结果。
Daybreak Blue 是这次发布中公开细节最少的部分。OpenAI 表示，通过 Daybreak Blue 提供的具备网络攻防能力的模型访问权限默认包含在内，无需另行申请 Daybreak Blue。截至访问日期，OpenAI 未公布独立的 Daybreak Blue 页面或模型清单，因此无法说明涉及哪些模型，也无法说明它们的能力画像。任何点名 Daybreak Blue 模型的摘要，都是超出已公布材料的推断。
关于成熟度的这两种描述并不直接冲突，合起来读比只取其一更有用。「研究预览」描述的是 OpenAI 在自家发布流程中把产品放在什么位置；套餐清单描述的是谁能触达它。计划试点的团队应当把「预览」标签当作关于稳定性和变更频率的支配性表述，把套餐清单当作实际的可用性检查。这一组合意味着功能在这些套餐上可触达，同时界面、流水线或输出格式仍可能在没有弃用周期的情况下变动——这正是把威胁模型和任何自动化保持轻薄的论据，而不是去构建一条依赖某个 JSON 字段存续的流水线。
从这两个事实得出的务实结论是一样的：把它当作一次在你自有仓库上、有监督的试点，为威胁模型指定负责人，也为分诊队列指定负责人。这个工具做的是真工作，而它取代的工作，正是你本来就应该在做的工作。
两篇姊妹文章提供了周边背景。面向智能体开发者的 DevDay 2026 回顾 覆盖了同一天公布的其他六项 Codex 与 API 内容，面向编程智能体的 GPT-6.1 Sol 覆盖的则是决定一条以验证为主的流水线是否负担得起按计划运行的成本模型经济性。如果「安全技能」这个说法对你还陌生，什么是智能体技能？解释了这些工作流是如何打包的。
常见问题
Codex Security Cloud 和 Codex Security 是同一个东西吗？ 不是。Codex Security Cloud 在 Codex cloud 中扫描已连接的 GitHub 仓库，是本指南的主题。Codex Security 插件则在桌面应用或 CLI 的 Codex 任务中运行本地扫描。
它会取代我的 SAST 工具吗？ 不会。OpenAI 表示它补充 SAST，在 SAST 继续提供广泛确定性覆盖的同时，增加基于模型的语义推理和自动验证。
它会取代人工安全审查吗？ 不会。文档明确说明它加速审查、帮助给发现项排序，但不替代代码级验证、可利用性检查或人工威胁评估。
它会自动应用修复吗？ 不会。某个发现项可能包含一份建议的最小补丁，你在选择 Create draft pull request 之前先审查它。工作流生成供检查的 diff 或补丁，不直接修改你的 PR 分支。
我可以在没有构建步骤的情况下扫描仓库吗？ 发现项可以在没有编译步骤的情况下从仓库和提交上下文产出。自动验证期间，如果有助于复现问题，工具仍可能尝试在容器内构建项目，因此一个可构建的环境能提升验证质量。
验证失败时会怎样？ 发现项保持未验证，日志和报告记录下尝试过的内容。你可以重试、进一步调查，或调整复现步骤。
哪些套餐包含它？ DevDay 回顾把桌面端和网页端的 Pro、Business、Enterprise 和 Edu 都列入。产品文档把它描述为研究预览。访问权限还可能需要在工作区级别启用，因此文档中「与工作区管理员确认」的建议是务实的第一步。
Daybreak Blue 是什么？ OpenAI 表示 Codex Security Cloud 默认包含通过 Daybreak Blue 提供的具备网络攻防能力的模型访问权限，无需另行申请 Daybreak Blue。未公布独立的 Daybreak Blue 页面或模型清单，因此具体模型未公开枚举。
资料来源
核对于 2026 年 9 月 29 日。
OpenAI —— 一手来源
- Codex Security（产品概览） —— 流水线、三个界面、隔离、访问前提
- Codex Security Cloud 设置 —— 安装、连接 GitHub、首次扫描、发现项、提交监控
- Codex Security Cloud FAQ —— 流水线阶段、隔离、验证行为、SAST 与人工审查限制
- 改进威胁模型 —— 威胁模型包含什么以及如何编辑
- Codex Security 插件快速入门 —— 本地插件，以及它与 Cloud 插件的区分
- Codex cloud —— 环境前提
- DevDay 2026 Recap —— 可用性表述与官方仪表盘图片
- @OpenAI on X —— 上方嵌入的 Codex Security Cloud 升级帖
- @OpenAIDevs on X —— 面向开发者的细节
@openai/codex-security—— 公开的 CLI 与 TypeScript SDK 包
