Codex Security CLIをいきなり必須ゲートにしない: 初回スキャンからCI導入まで¶

導入判断

段階	判断
ローカル評価	`--dry-run`後、出力先と費用上限を固定してreport-onlyで試す
PR上のCI	同一repositoryの信頼できるPRだけを対象にし、結果を人間が確認する
required check	coverageと誤検知処理を測り、exit code 2も失敗として扱ってから有効化する

CLIとSDKがApache-2.0で公開されても、スキャン利用権とモデル利用費は別に残る。 最初からmergeを止めず、証拠を安定して残せることを確認してから強制力を上げる。

公開日: 2026-07-31

OpenAIは、脆弱性の発見、検証、修正支援を行うcodex-securityリポジトリを公開した。 CLIに加えてTypeScript SDKも含まれ、ソースコードはApache License 2.0で利用できる。¹²

ただし、導入判断を「オープンソースになったからCIへ追加する」で終えるのは早い。公開されているのはクライアントのソースであり、実際のスキャンにはCodex Securityへのアクセスが必要になる。³

この記事では2026年7月31日時点のnpm最新版0.1.4をインストールし、バージョン表示と--dry-runまで確認した。利用権と費用を伴う実スキャンは実行していないため、検出率や所要時間の実測値は示さない。

Codex Security CLIをdry-run、report-only差分スキャン、人間のトリアージ、severity gate、修正検証の順に導入する工程図

OSS公開でもスキャン権限と利用費は別に残る¶

@openai/codex-securityはNode.js向けの公開パッケージで、codex-securityコマンドとTypeScript SDKを提供する。公式READMEはmacOS、Linux、Windowsを対応対象とし、Node.js 22.13以降の対応系列とPython 3.10以降を前提にしている。¹

一方、CLIでログインできることとスキャン権限が付与されていることは同義ではない。公式ドキュメントは、スキャン実行にCodex Security accessが必要であり、対象によってはTrusted Access for Cyberが必要になると説明する。³⁴

さらに--max-costは見積もり上限であり、厳密なhard capではない。進行中のリクエストが完了することで指定額を超える可能性があるため、最初から無人の全リポジトリスキャンへ進めるべきではない。⁵

公開されたもの	別途確認するもの
CLIとTypeScript SDKのソース	Codex Securityの利用権
Apache-2.0ライセンス	モデル利用費と予算管理
ローカル実行とCI統合の仕組み	ソース送信、結果保持、社内承認
SARIF、JSON、CSVへのexport	GitHub Code Securityなど受け側の契約

初回スキャンは出力先と費用上限を先に固定する¶

評価環境では、利用するバージョンを明示してから設定だけを検査する。 2026年7月31日時点の確認例は次の通りである。

npm install @openai/codex-security@0.1.4
npx @openai/codex-security --version
npx @openai/codex-security login
npx @openai/codex-security scan . --dry-run

--dry-runは入力と設定を検査し、資格情報の検証、Python runtimeの起動、ネットワークアクセスを行わない。 SmartScopeの確認では0.1.4が表示され、対象リポジトリ、mode、出力先、認証方法、model、effortを含むpreflight結果が返った。⁵

実スキャンへ進む時は、結果を対象リポジトリやその親worktreeの外へ置く。結果にはソース抜粋、脆弱性の詳細、再現や修正に関する情報が含まれ得るため、公開artifactへ無条件で載せてはならない。⁴

SCAN_DIR="$(mktemp -d "${TMPDIR:-/tmp}/codex-security.XXXXXX")"
npx @openai/codex-security scan . \
  --output-dir "$SCAN_DIR" \
  --max-cost 5

初回評価で記録するのはfinding数だけではない。対象範囲、完了またはincomplete、実行時間、推定費用、人間が再現できた件数、誤検知理由を一つの台帳へ残す。

CIは同一リポジトリのPRをreport-onlyで始める¶

公式CIガイドは、同一リポジトリから来た信頼できるPRだけを対象にする構成を示す。 forkやDependabotなどの信頼境界を越えるPRへsecretを渡さず、レビュー済みのCLIをcheckout前に固定導入し、checkout時のcredential保持も無効にする。⁶

PR差分だけを調べる核心コマンドは短い。ただし、次の断片だけで安全なworkflowが完成するわけではなく、event条件、権限、tool pinning、artifact保持期間は公式の完全例に合わせて設計する。

codex-security scan . \
  --diff "$BASE_REVISION" --head "$HEAD_SHA" \
  --auth api-key --output-dir "$SCAN_DIR" \
  --json > "$RUNNER_TEMP/codex-security.json"

導入初期は--fail-on-severityを付けず、結果をartifactまたはSARIFとしてレビューする。 privateまたはinternal repositoryでSARIFをGitHubへuploadする場合は、GitHub Code Security側の利用条件も確認が必要である。⁶

CLIの最新版と公式CI例の固定版が一致しない時は、機械的に最新版へ追従しない。変更履歴と依存関係をレビューし、承認した版を明示的にpinする。

severity gateはcoverageと誤検知処理を測ってから有効化する¶

既定のスキャンはreport-onlyである。 --fail-on-severity highを追加すると、完了したスキャンでhigh以上のfindingが見つかった時にexit code 1を返せる。⁵

codex-security scan . \
  --diff "$BASE_REVISION" --head "$HEAD_SHA" \
  --fail-on-severity high \
  --auth api-key --output-dir "$SCAN_DIR"

重要なのはexit code 1だけではない。入力不正、runtime error、coverage不足などはexit code 2であり、「脆弱性なし」を意味しない。

exit code	意味	CIの扱い
0	完了し、設定したseverity gateを通過	次工程へ進める
1	閾値以上のfindingを検出	人間のトリアージまで停止
2	入力、runtime、incomplete coverage	検査失敗として停止
130 / 143	中断または終了signal	再実行条件を確認

required check化の条件は、数回greenになったことではない。 incompleteを検知できること、false positiveに理由を付けられること、artifactを閲覧できる担当者が限定されること、timeoutと費用超過時の扱いが決まっていることが先である。

修正確認はrerun、compare、validateを分けて使う¶

一度の再スキャンでfindingが消えても、修正済みとは限らない。対象範囲が変わった場合やcoverageが不足した場合、以前のfindingはresolvedではなくunknownとして扱う必要がある。⁵

Codex Security CLIはscan history、rerun、match、compare、validateを分けて提供する。同じ対象を再評価するrerun、前後のfindingを対応付けるmatchとcompare、特定の修正を検証するvalidateは目的が異なる。

codex-security scans rerun "$SCAN_ID"
codex-security scans match "$BEFORE_ID" "$AFTER_ID"
codex-security scans compare "$BEFORE_ID" "$AFTER_ID"
codex-security validate findings.json "対象finding"

スキャンは非決定的であり、rerunしても同一結果が保証されるわけではない。最終判断では再現手順、対象test、既存のSAST、依存関係scan、secret scan、人間レビューを残す。

patchコマンドを使う場合は、現在のworktreeへ変更を書き込む前提で扱う。 cleanな専用branchまたはworktreeで実行し、diffをレビューしてからtestする。⁸

TypeScript SDKは複数リポジトリ運用の制御面を作れる¶

TypeScript SDKはCLIの単なる薄い別名ではない。 preflight、run、lifecycle callback、AbortSignal、target、出力先、費用上限をコードから制御できる。⁷

import { CodexSecurity } from "@openai/codex-security";

const security = new CodexSecurity();
await security.preflight({ repository: process.cwd() });
const result = await security.run({
  repository: process.cwd(),
  maxCostUsd: 5,
});

SDKが向くのは、複数リポジトリで共通の承認、予算、保持期間、通知を実装する場合である。一つのrepositoryを初めて試す段階では、CLIの明示的なcommand lineと保存された結果の方が監査しやすい。

Claude Securityとは実行場所と証跡で使い分ける¶

Codex SecurityとClaude Securityは、どちらもLLMを使う脆弱性探索だが、運用面の重心が異なる。 Claude Security pluginはClaude Code session内でmulti-agent scanを実行し、threat model、独立検証、手動適用するpatchを生成する。⁹

Codex Security CLIは、repository、path、diff、working treeを対象にでき、scan history、compare、false-positive状態、SARIF、severity exitを持つ。 CIや複数repositoryの証跡をそろえる制御面では、CLIとSDKの形が使いやすい。

観点	Codex Security CLI / SDK	Claude Security plugin
主な実行場所	shell、CI、Node.js program	Claude Code session
対象指定	repository、path、diff、working tree	repository全体または差分
証跡	history、JSON、CSV、SARIF、compare	timestamp付きscan結果とpatch
強制力	report-onlyまたはseverity exit	人間が結果とpatchを承認
向く場面	定期実行、CI、複数repo統制	対話的な深掘りと脅威モデル

Anthropicの別repositoryにあるClaude Code Security Review Actionは、PR差分へのcommentを中心とする旧来のCI経路である。同repository自身がprompt injectionに対してhardenedではないと警告し、信頼できるPRだけでの利用を求めるため、現行pluginと混同しない。¹⁰

既存のSASTと人間レビューは残す¶

Codex Security CLIの価値は、従来のscannerが見つけにくい文脈依存の脆弱性へ探索範囲を広げられる点にある。その価値は、決定的なrule engineや人間の責任を外せることを意味しない。

安全な導入順は、ローカルの--dry-run、費用を限定した全体評価、同一repo PRのreport-only差分scan、人間のトリアージ、severity gate、修正後のvalidateである。この順番なら、OSS公開というニュースを、止まり方と証拠が定義された開発工程へ変換できる。