Codex Security Cloud 怎么用？仓库扫描、修复建议与审查流程

Codex Security Cloud 是面向已连接 GitHub 仓库的云端安全扫描插件。当前处于 research preview，可运行一次仓库扫描，也可监控默认分支的新提交；它会生成威胁模型、调查潜在漏洞并提供验证证据或修复入口。正确流程不是“一键扫描后直接合并”，而是确认仓库与修订、阅读攻击路径和验证前提、人工判断适用性，再审查补丁与测试。

先选对入口：Cloud、插件、Security Review 不是同一项

如果目标是“先给整个仓库做基线扫描，再持续关注新提交”，使用 Security Cloud；如果代码只在本地，使用单独的 Security 插件；如果只想检查一个 PR，查看 Codex GitHub Review 与 Security Review 的差异。

开始前需要准备什么？

1. 确认访问资格：在 ChatGPT 网页或桌面应用的 Plugins 中能找到并启用 Codex Security Cloud；若被管理员禁用，联系 workspace 管理员。
2. 确认 Codex Cloud：工作区已设置可用的 Codex Cloud 环境。环境决定依赖、工具和验证时可用的运行条件。
3. 确认个人 GitHub 连接：每位启动扫描的人都要使用自己的 GitHub 连接并拥有目标仓库权限；Security Cloud 当前不支持用 workspace connection 代替。
4. 限制仓库范围：在 GitHub App 的 Configure access 中只开放需要扫描的组织和仓库。没有授权能力时，请 GitHub 管理员添加，不要扩大到无关仓库。
5. 准备验证条件：把可重复安装、构建和测试命令放进仓库规则，避免依赖个人电脑的隐式状态。环境无法运行验证时，扫描仍可分析源码，但结论会缺少运行证据。

第一次仓库扫描：按 6 步执行

1. 在 Plugins 中安装并打开 Codex Security Cloud，选择 Scan。
2. 按提示连接 GitHub，在 New Scan 中选择已经授权的仓库。
3. 检查 Cloud environment。Auto 会在开始时创建环境；需要固定依赖、私有包源或测试服务时，用 Customize 选择已配置环境。
4. 在 Scan Method 选择 One-Time Scan，再选择 Create。
5. 在 Scans 中等待完成，先核对状态、目标仓库、分支或修订；失败或取消的扫描只能算不完整审查。
6. 打开 Findings，逐条检查 affected code、攻击者到达路径、验证证据和未解决假设，再决定接受、继续调查或关闭。

One-Time Scan 和 Continuous Scanning 怎么选？

持续监控的设置是仓库在 workspace 中的共享配置。扫描 owner、获得编辑权限的人和 Security 管理员可以修改环境、历史窗口、威胁模型或暂停监控；改动不是只对当前操作者生效。开启前应明确谁负责处置发现和支付扫描用量。

威胁模型为什么必须人工补充？

Security Cloud 会从代码生成第一版 threat model，并用它指导后续提交扫描和发现排序。但代码通常无法说明真实部署边界，例如某个接口是否公网可达、谁能提供输入、租户隔离如何实现、哪些服务拥有高权限。因此要在 Repositories → 目标仓库 → Monitoring settings 中检查并补充：

• 入口与不可信输入：HTTP、文件上传、Webhook、消息队列或导入任务；
• 信任边界：身份验证、授权、租户隔离和服务间调用假设；
• 敏感数据与高权限动作：密钥、账单、账户变更、文件系统或部署控制；
• 优先区域与明确未知：告诉扫描器重点，同时不要把未经证实的部署假设写成事实。

威胁模型的修改只影响未来扫描。认证、租户边界或外部暴露面变化后，应重新检查模型，不要把旧模型当永久事实。

怎样复核一个 Finding，而不是只看严重级别？

严重级别和状态用于组织工作，不能替代证据。源码分析可以支持一条可利用路径；运行测试可以证明特定复现成功。若运行验证失败，既可能是不适用，也可能只是环境没有依赖、测试数据或服务，必须把两种可能分开。

如何判断误报并留下可审计记录？

1. 先复述 Finding 的攻击前提、信任边界和预期影响，不要只写“工具误报”。
2. 确认目标 revision 与当前部署一致；旧代码、生成文件或未部署路径要有证据。
3. 检查 Cloud 环境是否具备依赖、配置和测试数据；验证失败不等于自动排除。
4. 寻找补偿控制，例如上游授权、网络隔离或运行时策略，并证明它在目标环境真实存在。
5. 关闭时记录理由、证据、适用版本和复查条件；部署或边界改变后重新评估。

Fix with Codex、建议补丁和草稿 PR 的区别

仓库扫描中的 Fix with Codex 会启动一个 Codex 对话，让它结合当前代码重新核验问题、实施修改并运行相关测试。持续监控的 Finding 可能先给出 suggested patch，再由你选择创建 draft pull request。两条路径都不是自动生产修复：

• 先检查 Diff 是否只触及预期范围，是否引入新的权限、依赖或兼容性问题；
• 要求重新运行原复现、回归测试和正常业务路径；
• 没有完成验证时，把不确定性保留在 Finding 或 PR 中；
• 草稿 PR 不会自动合并，状态变化也不能证明漏洞已修复；
• 合并前准备回滚方式，并由有权限的人按正常代码审查流程批准。

如需检查单个 Pull Request 的安全变化，请转到 GitHub Review；如需限制 Cloud 环境的依赖、Secrets 与网络，请先完成 Codex Cloud 环境配置 和 权限边界检查。

扫描用量和费用怎么理解？

官方当前 FAQ 说明，Cloud 仓库扫描和持续扫描按 Token 用量计费，可依据账户或 workspace 的计费方案使用 credits 或 USD；这部分不包含在套餐的 included usage allowance 中。扫描详情页会显示 Token 与费用，并区分适用的免费扫描 credits 或计费豁免。

不要把 ChatGPT 订阅权益、Codex included usage、Security Cloud 扫描 credits 和 OpenAI API 余额混为一项。本站不保证免费额度、固定单次价格或持续扫描成本；开始前应在账号页面确认付费开关、剩余 credits 与实际显示。

看不到插件或仓库时怎么排查？

1. 插件不存在：确认是在 ChatGPT 网页或桌面应用，并让 workspace 管理员核对 Security Cloud access 与插件策略。
2. 仓库不在列表：在 repository picker 选择 Configure access，检查 GitHub App 的组织与仓库授权。
3. 连接后仍不可用：确认发起扫描的人使用自己的 GitHub 连接并拥有仓库访问权；workspace connection 不能替代。
4. 验证无法运行：检查 Cloud environment 的依赖、构建、测试服务和最小权限凭据；区分源码结论与未完成的运行验证。
5. 持续监控不能修改：联系扫描 owner、被授予 edit 的成员或 Security 管理员；不要尝试绕过共享配置权限。

常见问题

Codex Security Cloud 和本地 Codex Security 插件有什么区别？

Security Cloud 在 Codex 云端扫描已连接 GitHub 仓库并可监控新提交；本地插件在桌面端或 CLI 中扫描本地仓库。两者是独立入口。

使用 Codex Security Cloud 需要什么权限？

需要 workspace 具备访问权、已设置 Codex Cloud，并由启动扫描的人用自己的 GitHub 连接访问已授权仓库。当前不支持 workspace connection 代替个人连接。

One-Time Scan 和 Continuous Scanning 有什么区别？

前者执行一次仓库检查；后者监控默认分支新提交并可回看选定历史。建议先完成一次扫描、确认环境和解释流程，再开启持续监控。

扫描没有发现问题就代表仓库安全吗？

不代表。还要确认扫描完成、目标修订正确，并阅读覆盖范围、限制和未完成工作；自动扫描仍可能漏报。

验证失败可以直接判定为误报吗？

不能。它也可能由环境、依赖、测试数据或复现方法不合适造成。应先检查日志和源码证据，再补齐验证缺口。

Codex Security Cloud 会自动合并修复吗？

不会。Fix with Codex、建议补丁或草稿 PR 都需要人工检查 Diff、测试、证据与回滚方案；创建草稿不等于合并或修复完成。

Codex Security Cloud 扫描如何计费？

官方当前说明按 Token 用量计费，可根据账户或 workspace 计费方案使用 credits 或 USD，并且不包含在套餐 included usage allowance 中。具体免费 credits、豁免和费用以扫描页面为准。