用 Codex Security CLI 扫描代码仓库，并和团队一起分拣安全发现

报告写着“两个高危问题”，仍不足以决定先修哪个。团队还需要知道工具检查了哪些代码，以及每项发现有什么证据。本文带你对有权评估的仓库运行一次 Codex Security CLI 扫描，再把结果分为需要修复、需要核实和尚未充分检查的部分。安装和阅读报告可预留约30分钟；实际扫描时间取决于仓库和配置。

这是检查产品代码漏洞的流程，与团队用 Codex 修改代码时的权限和沙箱指南互为补充。前者评估产品风险，后者控制工具在工作时能访问什么。

准备工作

根据 OpenAI 的 Codex Security CLI 快速入门，@openai/codex-security 是公开的软件包，但运行扫描需要 Codex Security 使用权限。某些账户或仓库的全仓扫描还可能需要 Trusted Access for Cyber。能够安装软件包，不代表账户一定能扫描。安排团队使用前，先确认权限。

CLI 要求 Node.js 22.13.0 或更高的 22 版本，或 Node.js 24、26。扫描和查看已保存结果还需要 Python 3.10 或以上。只对自己拥有或获准评估的仓库操作，确认当前分支和结果负责人。如果还不熟悉终端，可先阅读从一个小任务开始并自行验证的 Codex CLI 指南。

扫描结果可能包含源代码片段和漏洞细节。请在仓库外的私有目录保存结果，并确定读取权限与保留期限。OpenAI 说明，本地扫描使用运行者的操作系统权限，不会暂停等待批准；进程也可能继承环境变量。开始前移除无关凭据，不要为了绕过配置问题而给予更高权限。

分步操作

1. 检查版本并登录

先检查 Node.js、Python 和 CLI。以下命令只检查环境，不会扫描仓库：

node --version
python3 --version
npx @openai/codex-security --version
npx @openai/codex-security info --json
npx @openai/codex-security --help

info --json 会显示软件包和随附插件的版本。不支持的 Node.js 版本应先处理。在可交互的机器上，使用具有扫描权限的 ChatGPT 账户登录：

npx @openai/codex-security login
npx @openai/codex-security login status

无浏览器的远程机器可用 login --device-auth。CI 通常通过环境变量提供 API 密钥，但仍需有相应扫描权限。如果同时存在 ChatGPT 登录状态以及 OPENAI_API_KEY 或 CODEX_API_KEY，应明确指定 --auth chatgpt 或 --auth api-key。默认的 auto 模式在交互终端和 CI 中可能选用不同凭据。不要在终端输出密钥，也不要把它写进团队文档。

2. 指定仓库和结果目录，先做配置检查

把下面的示例路径换成你机器上的绝对路径。SCAN_DIR 应位于 REPOSITORY 外，并限制读取权限：

REPOSITORY=/path/to/authorized-repository
SCAN_DIR=/path/outside-repository/security-results
npx @openai/codex-security scan "$REPOSITORY" --output-dir "$SCAN_DIR" --dry-run

OpenAI CLI 参考文档说明，--dry-run 检查本地输入，包括传入的知识库路径。它不加载凭据、不启动 Codex，也不探测插件的 Python 解释器。因此 dry run 成功不能证明账户有扫描权限，或正式扫描一定完成。它只帮助你提前发现路径和配置错误。

对于包含多个服务的仓库，可以加入 --path services/billing，从一个有明确负责人的范围开始。--knowledge-base 可为扫描提供架构图或安全政策，但要先检查文档是否包含不应共享的秘密。团队使用 Codex 的 AGENTS.md 规则用于日常协作；它的存在不代表扫描器已理解产品的全部信任边界。

3. 运行标准扫描并保留原始文件

确认 dry run 的仓库和输出目录正确后，运行标准扫描。下例明确选择 ChatGPT 登录；获批使用 API 密钥的环境可以改为 --auth api-key：

npx @openai/codex-security scan "$REPOSITORY" \
  --output-dir "$SCAN_DIR" \
  --auth chatgpt

扫描默认只生成报告，不会自动修复代码。交互终端会显示进度面板，普通输出将摘要和报告路径写到 stderr，不会把完整结果写到 stdout。分享进度截图之前先检查，因为会话细节可能包含源代码或凭据。只有自动化确实需要完整 JSON 文档时才加 --json。

扫描完成后查看 report.md、findings.json、coverage.json 和 scan-manifest.json。report.md 方便人工阅读；findings.json 记录严重程度、位置、证据和修复建议；coverage.json 记录已检查区域、排除部分与开放问题；scan-manifest.json 标明目标、范围和状态。写团队摘要之前，保留这些原始文件。

4. 根据证据和覆盖范围分拣

先读 coverage。OpenAI 使用 complete、partial 和 unknown 三种状态。若为 partial 或 unknown，记录哪些路径或功能未被检查。即使发现数量很少，也不能据此宣布被跳过的支付组件安全。即使状态是 complete，仍应核对扫描目标、排除项和未解决的问题。

把每项 finding 当作有待验证的假设。团队记录可以有三列：发现与证据、暂定决定、负责人及验证步骤。决定可以是“修复后重查”“继续调查”或“有明确理由的不适用”。严重程度有助于排序，但还需人工分析数据流、可触达性、实际部署配置和用户影响。

如果怀疑误报，先从保存的报告中找到 occurrence ID，再用 findings false-positive 写下具体理由。不能因为一个案例不适用就排除整类漏洞。根据 CLI FAQ，决定会作为该仓库后续扫描的背景，但扫描器仍会重新检查当前代码和可触达性。证据不足时，保留“继续调查”状态。

5. 用新扫描验证修复

某项 finding 没有出现在下一份报告中，单凭这一点不能证明问题已修复。旧发现可能继续保持开放，直到明确解决或撤销。负责人修改代码后，重跑原配置并比较结果：

npx @openai/codex-security scans list "$REPOSITORY"
npx @openai/codex-security scans rerun BEFORE_SCAN_ID
npx @openai/codex-security scans compare BEFORE_SCAN_ID AFTER_SCAN_ID

把 BEFORE_SCAN_ID 和 AFTER_SCAN_ID 换成真实 ID。确认新扫描覆盖了原问题所在路径，而不是对该区域给出 partial 或 unknown。随后用 validate 针对当前 checkout 重新检查原 finding。如果让 Codex 生成补丁，仍需审阅 diff 并运行测试。--patch 是显式选项，标准的只生成报告扫描不会自动启用它。

示例结果

假设一个仓库有文件下载缺少权限检查的 finding，另一条数据库警告可能是误报，且 webhook 部分未被完整检查。团队将下载问题交给负责人，保留数据库警告的调查状态，并安排重新检查 webhook。只有重扫和 validate 都确认修复后，才关闭第一项。这是说明流程的假设情景，不是实际仓库的扫描输出。

让结果更有用的做法

先对一个仓库或一个有负责人的服务运行标准扫描。理解初始报告后，再扩展到 deep scan、diff scan 或提交前检查。在大型仓库中，--path 可以与服务责任边界对应。对于 pull request，--diff origin/main --head HEAD 检查已提交的变更，--working-tree --base HEAD 检查未提交的变更。这两种变更扫描要求仓库参数指向 Git worktree 根目录。--path、--diff 和 --working-tree 不能一起使用。

如果团队有预算限制，可以设置 --max-cost。当估算模型费用超过限额时扫描会停止，但已经进行中的请求可能使费用略超限；提前终止的 deep scan 可能只得到 partial 覆盖。记录每次扫描的 ID、日期、分支、commit、范围和审核人，避免日后比较不同目标。报告为工程决策提供依据，不能替代代码审查和适当的安全测试。

使用限制

扫描需要 Codex Security 权限，有时还需要 Trusted Access for Cyber。CLI 能读取操作系统账户可读的内容，扫描时不会暂停请求批准。只扫描获准评估的仓库，移除无关凭据，并将结果保存在私有目录。不要公开发布源代码片段或漏洞报告。变更推理服务提供商或存储位置前，应先核对组织的数据规则。

AI 辅助扫描可能漏报或误判，相同配置的重复扫描也可能产生不同结果。complete 描述的是本次扫描的覆盖范围，不是仓库绝对安全的认证。了解系统的人仍需验证重要发现和实际影响。本文命令已与 OpenAI 当前官方文档核对。由于示例未指定仓库及扫描权限，没有运行真实扫描。

常见问题

安装公开的 CLI 软件包后就能立即扫描吗？ 不能。扫描需要 Codex Security 权限，某些全仓扫描还可能需要 Trusted Access for Cyber。

Dry run 会消耗模型 token 或验证登录吗？ OpenAI 表示，--dry-run 仅检查本地输入，不加载凭据、不启动 Codex，也不探测插件的 Python 解释器。

没有 finding 就说明仓库安全吗？ 不能。应查看 coverage.json、扫描范围、排除项和开放问题。即使 coverage 为 complete，也不能保证找到了全部漏洞。

扫描能自动修复问题吗？ 有 --patch 选项，但默认扫描只生成报告。接受修改前应核查证据、批准范围、审阅 diff 并运行测试。

问题在下一次扫描中消失，就算修好了吗？ 不一定。应比较扫描，检查受影响代码的覆盖情况，并用 validate 对当前 checkout 重新验证原 finding。

官方来源：Codex Security CLI 快速入门、CLI 参考文档与 CLI FAQ，OpenAI Learn。核对日期：2026 年 10 月 5 日。#CodexSecurity #代码安全 #CodexCLI #AI编程 #VibeCoding