Codex Security Cloudとは？脆弱性の調査・確認・修正を進める仕組み

脆弱性の調査をクラウドで進める

Codex Security Cloudは、つないだGitHubのリポジトリを、Codexのクラウドでスキャンするプラグインです。検出結果を確認し、新しいコミットも見守ります。

検出結果には、該当するコード、検証の証拠、直し方の案が付いています。「Fix with Codex」を選ぶとパッチの案が作られ、内容を確認してから下書きのプルリクエストを作れます。人が確認して初めてPRになる、という流れです。

同じ名前の似たプラグインがあるので、整理しておきます。

Codex Security Cloud：GitHubのリポジトリを、クラウドでスキャン

Codex Security（別のプラグイン）：ローカルのリポジトリを、デスクトップ版・CLIでスキャン

• 出典：OpenAI「DevDay 2026 の振り返り」（新しいタブ）

Defense Factoryとは？「防御ループ」を回す仕組み

OpenAIは、なぜこの仕組みを作ったのでしょうか。公式のページによると、攻撃側が、広く使える公開モデルと、長く動くエージェントを悪用して、大規模に脆弱性を突けるようになってきたためです。

防御側には、自分のコードへ直接アクセスでき、最先端のモデルを使えるという構造的な強みがあります。それを活かして、脆弱性を継続的に発見・検証・修正する自動化された防御の運用が、Defense Factoryです。

中心にあるのは、5つの工程を回す「防御ループ」です。

見どころは、「見つけたら終わり」ではないことです。動的検証で本物かどうかを確かめ、担当者を割り当て、修正が効いたかまで確認します。ループの共通のメモとして、SECURITY.md（システムの文脈を書くファイル）が使われ、回すたびに学びが積み上がります。

OpenAIは、社内の集中対応（セキュリティスプリント）が、Defense Factoryの出発点になったと説明しています。

公式ページでは、250人以上を動員し、100以上のサービス領域を対象に、初日だけで緊急・優先度の高い問題を53件解決したと説明しています。掲載した図は、数値ではなく、防御ループの工程を示したものです。

検出結果の37%が重複として見つかり、19.5%が実行時に再現され、動的検証後の誤検知率は0.81%でした。修復は100%Codexで行われ、ロールバックされた修正は0.53%です。

ただし、これはOpenAI自身の環境での数字です。

始め方

公式の設定ガイドでは、プラグインの導入、GitHubの接続、単発スキャン、結果の確認、継続的な監視の順に説明しています。最初のスキャンと、継続監視は設定を分けます。

Codexのクラウド環境が必要です。ワークスペースでCodexクラウドを設定し、スキャンで使う環境を選びます（環境の作り方は、Codexクラウドの記事で確認できます）。

継続監視では履歴の期間、調査対象の範囲も指定します。あとからRepositoriesのMonitoring settingsで環境・履歴の期間・監視の一時停止を変更し、Saveで保存できます。生成された脅威モデルはProject contextで確認・編集します。

使うときの注意点

セキュリティのツールは、使い方を誤ると問題になります。公式の注意を、まとめます。

自分が所有しているか、評価する許可があるコードだけをスキャンする

検出結果は「確認済みの事実」ではなく、確認のための材料。証拠と、直し方の案を読んでから判断する

ローカル版には、より徹底する「ディープスキャン」があります。実行時間は長く、結果のばらつきは減りますが、公式も「ディープスキャンにも限界がある」として、カバーの範囲と、未確認の点を確認するよう勧めています

小さく始めるなら

個人や小さなチームなら、リポジトリを1つ選んで、「新しいコミットの見張り」から始めるのが現実的だと思います。すでに動いているコードを大量にスキャンするより、これから入る変更をチェックするほうが、検出結果が少なく、1つずつ確認しやすいからです。

そして、AIが「直しました」と言ったパッチも、下書きPRの状態で人が読む。ここは、コードレビューの機能とも相性がよさそうです。コードレビューの記事もあわせてどうぞ。

検出された問題を、修正まで確認する

脆弱性は、入力の扱いや権限の不備など、攻撃に使われる可能性がある問題です。検出結果に「危険」と書かれていても、対象のコードで再現できるか、どの条件で起きるかを確認します。公開されていないテスト環境で、影響範囲と優先度を整理する順番です。

修正案が出たら、問題が再現しなくなったことと、元の機能が動くことを両方確認します。たとえばファイルの読み取り範囲を制限した場合は、禁止するファイルを拒否するテストに加えて、読んでよいファイルを引き続き読めるテストが必要です。

調査するリポジトリと、テストで接続してよい外部サービスを先に決めてください。機密情報をログへ出さず、修正内容と再現条件を担当者が読める形で残します。検出した件数が多いことだけで、安全性が保証されたとは判断できません。