脆弱性診断ツールCodex Securityの導入ガイド：Cloud・PRレビュー・CLI

脆弱性診断ツールとしてのCodex Security：DevDay後にできること

Codex Securityでは、リポジトリ、プルリクエスト、開発者の作業コピーという3つの場所で、脆弱なコードを見つけられます。建物に例えるなら、建物全体の検査、改修案の確認、作業員が現場を離れる前の点検に相当します。同じシステムを、それぞれ異なる範囲から調べる仕組みです。

プルリクエストは、レビューを受けるために提出するコード変更案です。CLIはターミナルで実行するコマンドラインツール、CIはコード変更をきっかけに自動でチェックを実行する仕組みを指します。

Cloudは、手元のコンピューターを閉じている間も、検出結果を調査し、重複を除き、修正案を用意します。ただし、OpenAIは引き続き**research preview（研究プレビュー）**と位置づけています。9月29日のDevDay発表で、スケジュール実行と利用対象について説明が加わりましたが、Cloudが一般提供の製品になったわけではありません。DevDayの発表まとめ、現在の提供状況。

GitLabを使うチームは、CLIから始めてください。 現在のSecurity Cloudのセットアップでは、GitHubに接続します。通常のCodexがGitLabのマージリクエストに対応していても、それだけではSecurity CloudがGitLabに対応している根拠にはなりません。別途用意されているGitLab CI/CDガイドには、GitLab環境でサポートされているセキュリティチェックの実行方法が記載されています。

対象プランと、5人で使う場合の料金

日付の明記されたDevDay発表と現在のHelp Centerによると、Codex Security CloudはPro、Business、Enterprise、Eduで利用できます。Security Reviewも同じプランを対象とし、Plusは対象外と明記しています。どちらも、ワークスペースの権限とリポジトリへのアクセスを有効にする必要があります。Cloudの利用対象、Security Reviewの利用条件。

小規模な企業なら、Standard Businessを5席契約する場合のサブスクリプション料金が比較の目安になります。

トークン課金は、モデルが読み込んだ量と生成した量に基づきます。席単価は国や通貨によって異なる場合があります。上のサブスクリプション料金は、現在のBusiness FAQに基づく計算です。Cloudの現在の課金案内では、既存の利用者に通知し、有料利用の開始前に明示的な同意を求めるとしています。利用料を賄う資金がなければ、スキャンは一時停止します。5人分のスキャン利用料まで含めた総額は示されていません。Cloudの課金、サブスクリプション料金とAPI料金の違い。

すでにBusinessを契約しているなら、席の追加費用がゼロで済む場合もあります。それでも、スキャンとレビューの利用料は予算に入れる必要があります。月々の総額は、席の料金に、該当するCloud利用料、APIで実行するCIスキャン、ランナーの実行時間、必要に応じて契約するセキュリティダッシュボードの料金を加えたものです。

今回も最初の1か月が無料になる前提で予算を組まないでください。 無料利用の案内は3月6日の公開時に付されたもので、その後の1か月を対象としていました。現在の製品ページと課金ページからは、9月30日に同様の案内が改めて提供されたとは確認できません。公開当初の条件、現在の課金条件。

料金の比較対象として、Semgrepの有料Code製品は、コントリビューター1人あたり月額$30、5人なら月額$150と案内しています。また、Free Editionは最大10リポジトリ、10コントリビューターに対応します。つまり、5人のチームでも、既存のスキャナーはすべて購入が必要だと決めつけずに両方を評価できます。ただし、両者が提供するチェックの範囲は異なるため、料金の比較だけでセキュリティツールの構成を決めるべきではありません。Semgrepの料金。

1つのリポジトリを接続し、レビュー済みの修正につなげる

まずは、自分たちが仕組みを理解しているアプリケーションと、そのアクセス制御を説明できるレビュー担当者を選びます。脅威モデルとは、アプリケーションが何を守り、誰がアクセスでき、どこで別のシステムを信頼するかを短く記述したものです。検査員に「どの扉には鍵が必要か」を伝える設計図に相当します。

1. デスクトップ版またはWeb版の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が表示されていれば、パッチを生成して内容を確認します。レビュー後にCreate draft pull requestを使います。通常のテストを実行し、マージ前にコードの責任者にも確認を依頼してください。

この手順は、現在のCloudのセットアップ画面に沿っています。実行環境を用意すると、疑わしい問題を再現しやすくなります。ただし、すべての問題を検証できる保証はありません。検証時の動作。

継続的にチェックするには、Commit changesを選んで別のスキャンを作成します。RepositoriesからMonitoring settingsを開き、環境と履歴の対象期間を設定して、監視を有効にするか一時停止します。アーキテクチャが変わったら、Project contextで脅威モデルを更新します。DevDayの説明どおり、Cloudはリポジトリの定期スキャンにも対応します。ただし、現在のセットアップ手順には、実行間隔や利用枠の記載がありません。毎日のスキャンが一定回数まで含まれるとは想定できません。監視の設定、定期スキャン。

公開されたGogsのスキャン事例から、検出結果の優先度を判断する

Gogsの事例からは、検出結果をチケットにする前に、実際の運用環境を把握する必要があるとわかります。OpenAIは、Codex Securityが発見した問題の公開事例として、このリポジトリと以下の脆弱性を挙げています。これは提供元が公開したスキャン事例であり、本記事のために新たに実行したスキャンではありません。以下のトリアージ判断は、メンテナーのアドバイザリに基づく提案です。OpenAIが公開した検出結果。

CVE番号は、公開された脆弱性を識別する番号です。2要素認証（2FA）は、パスワードに加えて別の確認手段をログイン時に要求する仕組みです。

最初のアドバイザリでは、修正済みバージョンとして0.13.4と0.14.0+devを挙げています。次のアドバイザリでは0.14.0です。これは過去のアドバイザリにある「最初に修正されたバージョン」であり、今から古いリリースを選ぶよう勧めるものではありません。アップグレード前に、そのプロジェクトが現在サポートしているリリースを確認してください。Gogsの復旧コードに関するアドバイザリ、Gogsのアップロードに関するアドバイザリ。

トリアージの記録は、デプロイ済みのリビジョン、到達可能な入口、根拠、担当者、対応内容、修正を検証するテストに絞ります。検出結果は、対応対象として受け付ける、具体的な理由を添えて却下する、未解決として調査を続ける、のいずれかに整理できます。「修正済み」とするのは、変更後の動作を検証してからです。

自分たちのスキャンでも、同じ基準で判断してください。CLIが保存するレポートには、検出結果と調査範囲が記録されます。後のスキャンで以前の指摘が出なくなっても、修正された証拠にはなりません。また、誤検知のフィードバックを送っても、その種類の脆弱性が以後ずっと検出対象から外れるわけではありません。検出履歴とフィードバック。

PRのセキュリティレビューを自動化する

リポジトリ全体の初回評価を終えたら、次のチェックとしてプルリクエストのレビューを導入します。Codex settingsでリポジトリを選び、Review security vulnerabilitiesのAuto security reviewを有効にします。すべてのPRを対象にするならAll PRsを選び、希望者から導入するなら個人の設定を使います。

PR作成時に初回レビューを行うならOn PR open、コード変更のたびに繰り返すならOn every push、通常のCode Reviewと一緒に実行するならWhenever code review runsを選びます。Security Cloudで事前にスキャンしておく必要はありません。Cloudの脅威モデルを再利用することも、リポジトリ内の脅威モデルファイルへのパスを指定することもできます。Security Reviewの設定。

自動レビューは、初期設定ではHighとCriticalの検出結果を報告します。手動で依頼するレビューは、初期設定でMediumも含みます。それぞれのしきい値は個別に変更できます。手動で依頼するには、PRに@codex security reviewとコメントし、関連するタスクのSecurity Reportを開いて根拠全体を確認します。GitHubに投稿された検出結果は、そのPRの公開範囲に従います。

これはセキュリティに絞ったレビューです。通常のCode Reviewもセキュリティ上の問題を指摘することがあるため、結果が一部重なる可能性があります。より広く扱った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を確認してください。調査範囲の状態は、complete（完全）、partial（部分的）、unknown（不明）のいずれかです。問題の報告がなくても、調査を見送った範囲や未解決の疑問に目を通します。上のコマンドはCLIクイックスタートに沿っています。

コミット前のチェックは、npx @openai/codex-security@0.1.31 install-hookでインストールします。ステージ済みと未ステージの両方の変更をスキャンし、初期設定ではHighの検出結果とスキャンエラーがあるとコミットをブロックします。既存のpre-commitスクリプトは保持されます。両方の変更を調べるため、結果を判断するときは、無関係な実験コードを作業コピーに混ぜないようにしてください。フックの動作。

上のパッケージバージョンとコマンドは、本記事の準備時に確認しました。本記事では、認証を使って実行したローカルスキャンの結果、実測のスキャン時間、スキャン費用は示していません。

CIでCLIを実行し、SARIFを保存する

SARIFは、セキュリティの検出結果を記録する標準ファイル形式です。別のツールでも、ソースコードの該当箇所と一緒に問題を表示できます。ファイルを書き出すことと、ホスティング型のダッシュボードを契約することは、分けて判断してください。

必要なスキャン権限を持つアカウントまたはAPI組織のキーを、CODEX_SECURITY_API_KEYというCIシークレットとして登録します。このキーを使うと、ランナーは対話的なChatGPTサインインなしで認証できます。以下のGitHub Actionsの例は、同じリポジトリ内の信頼できるPRをスキャンします。ベースとヘッドの正確なリビジョンを比較し、SARIFを書き出して結果を保存します。公式CIテンプレートを基に、本記事で確認したパッケージバージョンに固定し、Highを基準にチェックを失敗させる設定から始めます。まずは指摘の共有だけにするなら、--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は、エラーまたは調査範囲の不足を示し、partialやunknownも含みます。指摘の共有だけに使うスキャンが成功しても、その結果が説明するのは選択した範囲についてです。安全性の証明書にはなりません。成果物のエクスポートと終了コード。

SARIFをGitHubのコードスキャンアラートとして表示するには、公式テンプレートのupload-sarifステップと必要な権限を追加します。公開リポジトリに対応しており、非公開リポジトリと内部リポジトリではGitHub Code Securityを有効にする必要があります。上の例のようにSARIFを成果物として保存すれば、非公開リポジトリ向けのダッシュボードが無料で使えると想定せずに、内容を確認できます。GitHubでSARIFを利用する条件。

GitLabでは、OpenAIの本番向けCI/CDテンプレートを使います。マージリクエストの差分、保護されたデフォルトブランチのスキャン、任意で有効にする定期スキャンを扱っています。GitLabの標準機能でSARIFを取り込むには、GitLab Ultimate 19.2以降が必要です。そのダッシュボードを使う権利がない場合は、通常のレポート成果物として保存する方法もあります。

CIでの実行にはランナーの権限が使われ、その環境を引き継ぐ場合もあります。無関係な認証情報をジョブに含めず、信頼できるソース変更を対象にしてください。予算を決めたら、--max-costの値を追加します。ただし、これは見積もりに基づく上限です。すでに処理中のリクエストによって、超過する可能性があります。CIの利用要件、費用の制御。

効果を期待できる5つの使い方

1. ログインやテナント間のアクセス制御を変更するSaaSチーム。 まず基準となるスキャンを実行し、脅威モデルを整え、PRのSecurity Reviewを有効にします。顧客に影響が出る前に、アカウント間の境界に関するミスを見つけられる可能性が高まります。認証の責任者にもレビューに参加してもらってください。
2. 古いアプリケーションを引き継いだ創業者。 機能追加の前にリポジトリをスキャンし、対応対象とした検出結果に担当者を割り当てます。これにより、把握できていないバックログを、根拠のある短い作業リストに整理できる可能性があります。全面的な書き直しを求めるだけで終わらせずに済みます。
3. マネージド型のセキュリティスキャナーがないGitLabチーム。 マージリクエストの差分をCLIでチェックし、SARIFと調査範囲の情報を成果物として保存します。すでに運用しているCIの中で、同じ手順によるレビュー記録を残せます。
4. 複数の顧客リポジトリを保守する制作・開発会社。 CLIの再開可能な一括スキャンを使い、顧客ごとにアーキテクチャの情報と検出履歴を分けて管理します。セットアップの繰り返しを減らし、保守の引き継ぎをより正確にできる可能性があります。一括スキャン。
5. 既存のセキュリティバックログに大量の指摘がたまっているチーム。 Codex Securityのバックログトリアージを使い、スキャナーの結果を現在のコードと制御に照らして調べます。どのチケットに開発時間を割くべきか、その判断の根拠が得られます。元のスキャナーも動かし続けてください。バックログのトリアージ。

Codex Securityを軸に提供できる2つのサービス

最も有望なのは、小規模チーム向けに導入後の運用まで支えるセキュリティサービスです。 創業者が対価を払う対象は、セットアップ、脅威モデルの整備、CI連携、人による継続的なトリアージです。スキャンボタンを別の画面で包み直すだけのサービスではありません。

今回取得したDataForSEOの米国Google向け推定値では、“software vulnerability scanning”は月間720件、“code security scanner”は90件の検索がありました。これは検索数であり、有料顧客の数ではありません。また、広いほうの検索語には、リポジトリスキャン以外の用途も含まれます。Semgrep Codeの5コントリビューター分、月額$150という料金は、対象を絞ったサービスの具体的な比較基準になります。料金比較の基準となるSemgrep。

最小限の販売可能なサービスなら、顧客が所有する1つのリポジトリ、文書化した脅威モデル、CIワークフロー、レビュー済みの検出結果一覧を対象にできます。顧客のアクセス権を使い、利用料を見えるようにしてください。難しいのは運用です。誤解を招く検出結果を退け、慎重に扱うべき修正をレビューできるだけのアプリケーションへの理解が必要です。安全を保証するサービスとして売り出すのは、得られた根拠を超える主張になります。

もう1つは、制作・開発会社向けのリリース時の検証記録パックです。 顧客への引き渡しごとに、スキャン範囲、対応対象とした検出結果、残る不足、検証済みの修正を、日付付きの記録として提供できます。広い検索語である**“vulnerability scanning tools”の米国での推定月間検索数は1,900件**です。ただし、これは複数のセキュリティ領域にまたがるツールへの関心を示す数値です。顧客へのヒアリングで確かめる仮説には使えますが、このサービスそのものの需要を示すものではありません。

MVPでは、保存済みのスキャン成果物と承認済みのトリアージを、簡潔な顧客向けレポートにまとめることができます。課題は、結果の持ち運びやすさと信頼です。SARIFは持ち運べても、事業としての価値は、不完全な調査範囲も含めて結果を誠実に読み解くことから生まれます。レポートを自動生成するだけなら、容易に模倣されます。ここで示した検索数はすべて、2026年9月30日に取得したDataForSEOの月間キーワード推定値です。市場の成長や購入意向を裏づけるものではありません。

引き続き必要なチェックと、人によるレビュー

アプリケーションが取り込むパッケージとバージョンを確認する依存関係スキャンと、漏えいした認証情報を検出するシークレットスキャンは継続してください。リポジトリの内容を推論によって調べる仕組みでも、関連する問題を調査できます。ただし、パッケージ一覧の完全な把握や、認証情報の監視をすべて担うものではありません。

広範囲を再現可能な方法でチェックする必要がある場合や、保証要件が求める場合は、決まったルールに基づくSASTも維持してください。OpenAIも、Codex SecurityはSASTを補完すると明記しています。有料のスイートを購入せずにエージェントを試せるからといって、既存のチェックが不要になるわけではありません。CloudのFAQ。

認可に関するコードには、人によるレビューを残してください。認証が確認するのは「誰であるか」、認可が確認するのは「どの顧客のデータや操作にアクセスできるか」です。こうしたルールは、業務上の意図や運用環境の前提に依存し、スキャナーが誤解する可能性があります。責任者に、テナント間の境界、管理者権限、復旧フロー、回帰テストを確認してもらってください。これは、人による脅威評価が必要だという提供元の説明にも沿う、開発上の推奨事項です。

スキャン環境がアクセスできる範囲も限定してください。Cloudは隔離されたコンテナーを使い、ローカルとCIのスキャンは、その環境の権限を使います。サンドボックスのセキュリティガイドでは、エージェントが到達できる範囲を制御するという、別の課題を扱っています。

CodexとClaude Codeのセキュリティレビュー、どちらを選ぶべきですか？

すぐに必要なのが、まだ取り込んでいない変更へのセキュリティチェックで、チームがすでにClaude Codeを使っているなら、そのまま活用できます。ローカルで/security-reviewを実行するか、Anthropicのセキュリティレビュー用GitHub Actionを設定すると、PRへのコメントと誤検知のフィルタリングを利用できます。これらの機能は、有料のPro/MaxやAPI Consoleのアカウントを含む、Claude Codeの利用者が使えます。Claudeのセキュリティレビュー設定。

マネージド型でリポジトリ全体の基準を把握し、コミット監視、定期スキャン、修正案の準備まで行いたいなら、Codex Security Cloudを選びます。検出履歴の保存、調査範囲の成果物、SARIFのエクスポートがローカルやCIの工程に合うなら、CLIを選びます。この比較では、精度や費用でどちらが優れているかは確認されていません。

どちらを使う場合も、フィルタリング方針を確認してください。Anthropicのセキュリティレビュー用Actionは、サービス拒否やリソース枯渇などを除外対象として記載しています。Gogsのアップロード事例のようなディスク枯渇の懸念があるなら、この方針を意識して確認する必要があります。このActionは、Claudeのホスティング型Code Review製品とは別に提供されています。Anthropicのセキュリティレビュー用リポジトリ。

月曜日には、1つのリポジトリに1人の責任者を置きましょう。基準となるスキャンを実行し、脅威モデルを修正し、最初の検出結果をトリアージします。重大度に応じて処理を止める基準を選ぶ前に、まず指摘の共有だけを行うCIを追加してください。別のリポジトリへ広げる前に、利用料と、まだ調査できていない範囲を記録します。

チームの既存の開発工程に組み込みたい方に向けて、本番環境で使えるAIシステムを構築しています。