Codex Security Overview：插件、本地扫描和云端安全能力

适用场景

Codex Security 用于发现、审查和修复代码中的安全问题。它分成两类常用入口：

• Codex Security plugin：在 Codex 线程中运行，适合本地扫描、审查 diff、triage findings 和修复已确认问题。
• Codex Security cloud：通过 Codex Web 扫描连接的 GitHub 仓库，适合团队级持续发现和管理。

这篇文章是总览，用来帮助你判断应该从哪个入口开始。

两种入口怎么选

| 入口 | 适合场景 | 注意事项 | | --- | --- | --- | | Security plugin | 本地仓库、单次扫描、PR 变更审查、手动 triage | 需要安装插件并在 Codex thread 中运行 | | Security cloud | 连接 GitHub 仓库、持续扫描、团队级 findings 管理 | 当前为 research preview，依赖 Codex Web 和仓库授权 |

如果你是个人或第一次试用，先从 plugin quickstart 开始。
如果你是团队安全负责人，先评估 cloud setup、权限、扫描节奏和 findings 流程。

Codex Security 能做什么

官方页面列出的插件工作流包括：

• 运行标准安全扫描。
• 运行更深入的 deep scan。
• 审查 PR 或分支中的安全风险。
• triage 已有 backlog findings。
• 修复并验证 findings。
• 导出或跟踪 findings。
• 查看插件 changelog。

这些能力覆盖的是“发现、判断、修复、跟踪”的闭环。

Codex Security cloud 怎么工作

官方文档说明，Codex Security cloud 会基于连接的仓库逐 commit 扫描。它会构建 repo-specific context，针对可能漏洞做验证，并把高信号问题展示出来。

它强调三件事：

• 使用仓库上下文，而不是只靠通用签名。
• 提供验证证据，减少误报。
• 给出可审查的修复建议。

团队使用时，应把它纳入已有安全流程，而不是替代所有人工安全审查。

接入前检查清单

上线前确认：

• 仓库是否已经连接到 Codex Web。
• 哪些用户或组能查看 findings。
• 扫描结果是否会进入 GitHub、Jira、Linear 或内部系统。
• 是否需要修改 threat model。
• 是否有误报、不可复现、第三方依赖风险的处理规范。
• 是否允许 Codex 创建修复 PR。

安全工具最怕“发现了但没人处理”。接入前先定义 owner 和 SLA。

和 sandbox、approval 的关系

Codex Security 仍然运行在 Codex 的权限模型之内。扫描、导出、跟踪、修复时可能涉及：

• 读取仓库代码。
• 调用插件或连接器。
• 写文件或生成 patch。
• 创建 issue、PR 或 advisory。
• 访问外部系统。

这些动作仍然应该受 sandbox、approval、plugin 权限和管理员策略控制。

常见错误

不要把 scanner severity 直接等同于修复优先级。Codex Security 的价值在于结合可达性、信任边界和仓库证据判断。

不要把 needs_review 当成低优先级。它可能只是缺少运行时证据，需要人工或 validation 补充。

不要让自动修复直接合并。安全修复要看证据、测试和回归风险。

小结

Codex Security 的最佳使用方式是先用插件跑通本地安全闭环，再评估 cloud 是否适合团队仓库。无论使用哪个入口，都应保留证据、审批、人工审查和可追踪的修复流程。