Codex CLI 安全扫描指南：打通 Cloud、PR 审查与 CI

DevDay 之后，Codex Security 能在哪些环节检查代码？

Codex Security 为团队提供了三个发现代码漏洞的入口：代码仓库、拉取请求，以及开发者本机的工作副本。可以把它们想成对整栋建筑的检查、对改造方案的审核，以及工人离场前的检查。面对的是同一个系统，检查范围各有侧重。

拉取请求（PR）是等待审查的代码变更提案。CLI 是在终端运行的命令行工具；CI 则是代码变化时自动执行检查的流程。

即使电脑已经合上，Cloud 也能继续调查问题、去重并准备修复。OpenAI 仍将它定位为研究预览。9 月 29 日的 DevDay 公告补充了定时扫描和开放范围，并不意味着 Cloud 已正式全面开放。DevDay 回顾、当前产品状态。

**GitLab 团队应先从 CLI 入手。**目前 Security Cloud 的配置流程连接的是 GitHub。通用 Codex 支持 GitLab 合并请求，并不能据此认定 Security Cloud 也支持 GitLab。独立的 GitLab CI/CD 指南介绍了在这套开发环境中运行安全检查的受支持方式。

哪些套餐可以用？五人团队要花多少钱？

根据注明日期的 DevDay 公告和当前帮助中心，Pro、Business、Enterprise 和 Edu 均可使用 Codex Security Cloud。Security Review 列出的也是这些套餐，并明确排除 Plus。工作区权限和仓库访问仍需启用。Cloud 开放范围、Security Review 使用资格。

对小公司而言，可以用五个 Standard Business 席位来比较订阅成本：

按 token 计费，取决于模型读取和生成的内容量。席位价格可能因国家和币种而异。上表的订阅费用计算依据当前 Business 常见问题。Cloud 当前的计费说明指出，现有客户会提前收到通知，并须主动选择开启付费用量；没有可用资金时，扫描会暂停。这些说明并未给出包含全部费用的五人团队扫描报价。Cloud 计费说明、订阅与 API 计费的区别。

如果团队已经订阅 Business，新增席位成本可能为零，但扫描和审查用量仍要计入预算。每月总成本包括席位费、适用的 Cloud 用量费、通过 API 执行的 CI 扫描、执行器运行时间，以及可能选购的安全看板订阅。

**不要把新的首月免费期算进预算。**免费使用活动对应的是 3 月 6 日的首次发布，覆盖其后的一个月。当前产品和计费页面没有确认在 9 月 30 日重新推出该活动。最初发布时的条款、当前计费条款。

作为价格参照，Semgrep 的付费 Code 产品标价为每位贡献者每月 $30，五位贡献者共 $150。其 Free Edition 也支持最多 10 个仓库和 10 位贡献者。因此，五人团队可以同时评估两者，不必假定现有扫描工具都需要付费购买。它们的覆盖方式不同，不能只凭价格决定安全工具组合。Semgrep 价格。

先接入一个仓库，再把修复交给人工审查

先选一个自己熟悉的应用，再找一位能够解释其访问规则的审查者。威胁模型是一份简短说明，写清应用保护什么、谁能访问，以及它在哪些环节信任其他系统。它就像建筑图纸，帮助检查者判断哪些门应该上锁。

1. 在桌面或网页版 ChatGPT 中打开 Plugins（插件）。安装并启用 Codex Security Cloud，然后打开 Security Cloud。
2. 选择 New scan（新建扫描）。如果系统提示连接 GitHub，就授权访问要评估的仓库。
3. 选择仓库和兼容的 Cloud environment（云端环境）。必要时新建环境，配置项目所需的依赖和测试。
4. 在 **What to scan（扫描内容）**中选择 Repository（仓库），再点击 Start scan（开始扫描）。在 **Scans（扫描）**中查看进度。
5. 打开 Findings（发现的问题），阅读受影响代码、验证证据和修复建议。验证尝试失败，意味着证据仍待查明，不能据此排除漏洞。
6. 如果提供 Fix with Codex（用 Codex 修复），生成补丁并检查，审查后再使用 Create draft pull request（创建草稿拉取请求）。运行常规测试，并在合并前让代码负责人参与审查。

以上操作对应当前的 Cloud 配置界面。配置环境有助于复现疑似缺陷，但不保证每个问题都能得到验证。验证机制。

要持续检查提交，可以再创建一次扫描，选择 Commit changes（提交变更）。在 **Repositories（仓库）**下打开 Monitoring settings（监控设置），选择环境、设置历史窗口，并启用或暂停监控。架构发生变化时，在 **Project context（项目上下文）**中更新威胁模型。DevDay 公告还介绍了 Cloud 的定时仓库扫描，但当前配置指南没有给出调度频率或配额，不能自行假定每天有多少次扫描额度。监控配置、定时扫描。

Gogs 代码漏洞扫描案例：发现问题后如何研判？

Gogs 的案例说明，扫描结果在转成任务之前，必须先结合部署情况判断。OpenAI 在已公开的 Codex Security 发现中，列出了这个仓库及以下漏洞。这是供应商公开的扫描案例，并非本文新执行的扫描。下表的研判建议依据维护者发布的安全公告。OpenAI 公开的发现。

CVE 编号用于标识已披露的漏洞。双因素认证（2FA）是在密码之外增加一道登录验证。

第一份公告列出的修复版本为 0.13.4 和 0.14.0+dev；第二份为 0.14.0。这些是历史公告记录的首次修复版本，并非建议现在安装旧版本。升级前应检查项目目前仍受支持的版本。Gogs 恢复码漏洞公告、Gogs 上传漏洞公告。

研判记录保持精简即可：部署的代码修订、可访问入口、证据、负责人、处理措施，以及用于验证修复的测试。可以确认问题成立，也可以给出具体理由后排除，或保留为待调查。只有验证了行为变化，才能标记为已修复。

自己的扫描也应遵循同样的原则。CLI 保存的报告会记录问题和覆盖范围。后续扫描没有再次报出某个问题，并不能证明它已修复；提交误报反馈，也不会永久屏蔽这一类漏洞。问题历史与反馈机制。

如何开启自动 PR 安全审查？

完成首次仓库评估后，可以把拉取请求审查作为下一层检查。在 **Codex settings（Codex 设置）**中选择仓库，在 **Review security vulnerabilities（审查安全漏洞）**下开启 Auto security review（自动安全审查），选择 All PRs（所有 PR）；如果希望先由个人自愿启用，也可以使用个人偏好设置。

选择 On PR open（创建 PR 时），进行首次审查；选择 On every push（每次推送时），随代码变化重复审查；选择 Whenever code review runs（每次代码审查运行时），与通用 Code Review 一起执行。已有 Security Cloud 扫描并非必需。可以复用它的威胁模型，也可以指定仓库内威胁模型文件的路径。Security Review 配置。

自动审查默认报告高危（High）和严重（Critical）问题；手动发起的审查默认还包含中危（Medium）问题。两种审查的阈值可以分别调整。要手动发起，在 PR 下评论 @codex security review，再打开关联任务的 **Security Report（安全报告）**查看完整证据。发布到 GitHub 的问题会继承该 PR 的可见范围。

这项功能专门做安全审查。通用 Code Review 也可能发现安全问题，两者有一定重叠。Codex 审查指南介绍了如何在流程中安排不同类型的审查。

Codex CLI 如何安装，并接入提交前检查？

CLI 把同类仓库调查能力封装成了可通过脚本调用的命令行工具。源码采用 Apache 2.0 许可证，公开的 npm 包名为 @openai/codex-security。源码公开不等于扫描权限不受限制。官方源码与许可证、CLI 使用前提。

Cloud 内含的 Daybreak Blue 模型访问权限仅限 Cloud，不会同时赋予其他 Security 产品或 API 对该模型的访问权。把扫描移到 CI 之前，应先确认计划使用的登录方式和模型权限。产品访问权限边界。

几个日期需要区分清楚：GitHub 仓库创建于 2026 年 7 月 13 日；目前公开的历史从 7 月 15 日的初始化提交开始，npm 发布记录则始于 7 月 28 日。仅凭 7 月 13 日的仓库创建日期，不能证明采用该许可证的 npm CLI 当天就已发布。需要可重复配置时，应固定包版本。仓库元数据、初始化提交、npm 发布历史。

运行环境需要 Node.js 22 系列中的 22.13.0 或更高版本、Node 24 或 Node 26，以及 Python 3.10 或更高版本。在仓库目录中登录，并将输出放到检出目录之外：

npx @openai/codex-security@0.1.31 login
npx @openai/codex-security@0.1.31 scan . --auth chatgpt \
  --output-dir ../codex-security-results --dry-run
npx @openai/codex-security@0.1.31 scan . --auth chatgpt \
  --output-dir ../codex-security-results

检查 report.md、findings.json 和 coverage.json。覆盖状态可能是完整、部分或未知；即使没有报告问题，也要阅读暂缓检查的区域和未解决的问题。这些命令依据 CLI 快速入门。

使用 npx @openai/codex-security@0.1.31 install-hook 安装提交前检查。它会扫描已暂存和未暂存的变更，默认拦截高危问题和扫描错误，并保留已有的 pre-commit 脚本。由于两类变更都会被检查，解读结果时，工作副本中应避免混入无关的试验性改动。Hook 行为。

上述包版本和命令已在本文准备期间核对。本文没有声称执行过需要认证的本地扫描，也没有给出实测扫描时长或扫描成本。

把 Codex CLI 接入 CI，并保留 SARIF 报告

SARIF 是安全问题报告的标准文件格式，其他工具可以据此将每个问题展示在对应的源代码位置。导出报告文件和购买托管看板，是两个独立的决定。

在 CI 中创建名为 CODEX_SECURITY_API_KEY 的密钥，其所属账号或 API 组织须具备所需的扫描权限。执行器可以用它认证，无需交互式 ChatGPT 登录。下面的 GitHub Actions 示例扫描同一仓库内可信的 PR，使用其确切的 base 和 head 进行比较，导出 SARIF 并保留结果。它改编自官方 CI 模板，固定了本文核对过的包版本，并以高危级别作为初始拦截阈值。如果上线初期只希望提供建议，可以移除 --fail-on-severity high；扫描错误和覆盖不完整仍需处理。

保存为 .github/workflows/codex-security.yml：

name: Codex Security
on:
  pull_request:
jobs:
  security:
    if: github.event.pull_request.head.repo.full_name == github.repository && github.actor != 'dependabot[bot]'
    runs-on: ubuntu-latest
    permissions:
      contents: read
    steps:
      - uses: actions/setup-node@820762786026740c76f36085b0efc47a31fe5020
        with:
          node-version: '26'
      - uses: actions/setup-python@5fda3b95a4ea91299a34e894583c3862153e4b97
        with:
          python-version: '3.14'
      - name: Install trusted CLI outside the checkout
        run: npm install --prefix "$RUNNER_TEMP/security-cli" --ignore-scripts --no-audit --no-fund @openai/codex-security@0.1.31
      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1
        with:
          ref: ${{ github.event.pull_request.head.sha }}
          fetch-depth: 0
          persist-credentials: false
      - name: Scan and export
        env:
          OPENAI_API_KEY: ${{ secrets.CODEX_SECURITY_API_KEY }}
          CODEX_SECURITY_STATE_DIR: ${{ runner.temp }}/security-state
          BASE_SHA: ${{ github.event.pull_request.base.sha }}
          HEAD_SHA: ${{ github.event.pull_request.head.sha }}
        run: |
          set -euo pipefail
          cli="$RUNNER_TEMP/security-cli/node_modules/.bin/codex-security"
          out="$RUNNER_TEMP/security-results"
          base="$(git merge-base "$BASE_SHA" "$HEAD_SHA")"
          scan_exit=0
          "$cli" scan . --diff "$base" --head "$HEAD_SHA" \
            --auth api-key --output-dir "$out" \
            --fail-on-severity high --json \
            > "$RUNNER_TEMP/security-result.json" || scan_exit=$?
          if test -f "$out/scan-manifest.json"; then
            "$cli" export "$out" --export-format sarif \
              --source-root "$GITHUB_WORKSPACE" \
              --output "$out/results.sarif"
          fi
          exit "$scan_exit"
      - name: Keep reports, including SARIF when available
        if: always()
        uses: actions/upload-artifact@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a
        with:
          name: codex-security-results
          path: |
            ${{ runner.temp }}/security-results
            ${{ runner.temp }}/security-result.json
          retention-days: 7

这套工作流会在导出可用的已封存结果时，保留扫描退出码。退出码 0 表示所选范围覆盖完整，且通过设定的严重程度策略；退出码 1 表示某个问题达到了设定阈值；退出码 2 表示发生错误或覆盖不完整，包括部分覆盖或覆盖未知。仅提供建议的扫描即使显示通过，也只说明其选定范围内的报告结果，并不构成安全认证。产物导出与退出码。

如果希望把 SARIF 显示为 GitHub 代码扫描警报，需要添加官方模板中的 upload-sarif 步骤及相应权限。公共仓库受支持；私有和内部仓库需要启用 GitHub Code Security。按上面的方式将 SARIF 保存为产物，就能自行检查报告，但不能因此承诺私有仓库可免费使用托管看板。GitHub 的 SARIF 使用条件。

GitLab 团队可以使用 OpenAI 的生产环境 CI/CD 模板，其中包含合并请求差异扫描、受保护默认分支扫描，以及可选择启用的定时扫描。其原生 SARIF 导入需要 GitLab Ultimate 19.2 或更高版本。如果没有相应看板权限，仍可走普通报告产物这条路径。

CI 任务使用执行器的权限，并可能继承其环境。应移除任务中无关的凭据，只对可信的源代码变更运行扫描。确定预算后，再设置 --max-cost。这是估算上限，已经发出的请求仍可能使实际成本超出限额。CI 使用前提、成本控制。

五种值得尝试的用法，按收益排序

1. **正在修改登录或租户访问规则的 SaaS 团队。**先跑基线扫描，完善威胁模型，再为相关 PR 启用 Security Review。这样更有机会在客户遇到问题之前发现账号边界错误。让认证功能负责人参与审查。
2. **接手旧应用的创业者。**添加功能之前，先扫描一次仓库，为确认成立的问题指定负责人。这样可以把情况不明的待办事项，整理成一份有证据、范围明确的任务清单，而不是笼统要求重写整个应用。
3. **没有托管安全扫描工具的 GitLab 团队。**对合并请求差异运行 CLI 检查，将 SARIF 和覆盖报告保存为产物。收益是在团队现用的 CI 系统内，形成可重复执行的审查记录。
4. **维护多个客户仓库的服务商。**使用 CLI 可恢复的批量扫描，为每位客户分别维护架构上下文和问题历史。这有望减少重复配置，让维护交接更准确。批量扫描。
5. **现有安全待办中噪声过多的团队。**使用 Codex Security 的待办问题研判流程，结合当前代码和控制措施检查扫描结果，为哪些任务值得投入工程时间提供证据。原有扫描工具仍需运行。安全待办研判。

围绕它，可以做哪两类服务？

**最有潜力的方向，是为小团队提供持续维护的安全接入服务。**创业者购买的是配置、威胁模型梳理、CI 集成和定期人工研判，而不只是给扫描按钮再包一层界面。

本文准备期间，DataForSEO 的美国 Google 估算显示，“software vulnerability scanning”的月搜索量为 720，“code security scanner”为 90。这些是搜索次数，不是付费客户数；前一个更宽泛的词，也包含仓库扫描之外的需求。Semgrep Code 五位贡献者每月 $150 的价格，可以为范围明确的服务提供一个具体参照。Semgrep 价格参照。

最小可售版本可以覆盖一个客户自有仓库、一份成文的威胁模型、CI 工作流，以及经过审查的问题队列。使用客户的访问权限，并让用量成本清晰可见。难点在于实际运营：必须足够了解应用，才能排除误导性的发现，并审查敏感修复。承诺安全保证，会超出这些证据所能支持的范围。

**另一个方向，是为服务商提供版本发布证据包。**服务商可以在每次客户交接时，提供带日期的扫描记录，列出扫描范围、确认成立的问题、尚存缺口和已验证的修复。宽泛查询 “vulnerability scanning tools”的美国月搜索量估算为 1,900，但这反映的是多个安全领域的工具需求。它可以支持开展客户需求验证的假设，并不证明这个具体产品已有需求。

MVP 可以把保存的扫描产物和经批准的研判结果整理成简明客户报告。难点在于可移植性和信任：SARIF 文件可以流转，但商业价值来自如实解读结果，包括覆盖不完整的情况。单纯生成报告很容易被复制。所有搜索数据均为 2026 年 9 月 30 日获取的 DataForSEO 月度关键词估算，不能据此认定市场在增长，也不能证明购买意愿。

哪些安全检查仍然要保留？

保留依赖扫描，检查应用导入的软件包及其版本；也要保留密钥扫描，检测泄露的凭据。仓库推理可以调查相关问题，但不能充当完整的软件包清单或凭据监控系统。

如果确定性 SAST 的广泛、可重复检查，或安全保障要求对团队有价值，就应继续保留。OpenAI 明确表示 Codex Security 是对 SAST 的补充。可以不先购买付费套件就试用这个智能体，但已有的检查覆盖仍有必要。Cloud 常见问题。

授权代码仍需人工审查。认证回答“你是谁”，授权回答“你可以访问哪个客户的数据，或执行哪些操作”。这些规则取决于业务意图和部署前提，扫描工具可能理解错。应由负责人审查租户边界、管理员权限、账号恢复流程和回归测试。这是工程建议，也符合供应商关于威胁评估仍需人工参与的说明。

扫描环境的权限边界也要明确。Cloud 使用隔离容器；本地和 CI 扫描则使用本地权限。沙箱安全指南介绍了另一项独立工作：控制智能体能够访问什么。

Codex 和 Claude Code 的安全审查，该怎么选？

如果眼下需要的是检查待提交的变更，而且团队已经使用 Claude Code，可以继续沿用。既可以在本地运行 /security-review，也可以配置 Anthropic 的 security-review GitHub Action，在 PR 中发布评论并过滤误报。这些功能向 Claude Code 用户开放，包括付费 Pro/Max 和 API Console 账号。Claude 安全审查配置。

如果需要的是托管仓库基线、提交监控、定时扫描和预备修复，可以选择 Codex Security Cloud。如果本地或 CI 流程需要保存问题历史、覆盖产物和导出 SARIF，则选择其 CLI。本文的比较没有确立谁在准确率或成本上胜出。

无论采用哪套工具，都要检查过滤策略。Anthropic 的 security-review Action 文档列出的排除项包括拒绝服务和资源耗尽，因此，像 Gogs 上传案例中的磁盘耗尽风险，需要专门核查该策略。这个 Action 与 Claude 托管的 Code Review 产品是两个独立产品。Anthropic 的 security-review 仓库。

下周一，为一个仓库指定一位负责人。运行基线扫描，修正威胁模型，研判首批问题，再接入只提供建议的 CI，之后再决定严重级别拦截阈值。扩展到其他仓库前，先记录用量成本和仍未厘清的覆盖情况。

如果希望把这些能力接入团队现有的开发流程，我提供生产环境 AI 系统开发服务。