防御側に残された猶予は少なくなっています
防御側は先行していますが、私たちは行動しなければなりません
OpenAI のアプローチ
The Defense Factory
継続的な防御の構築
OpenAI のアプローチ
The Defense Factory
継続的な防御の構築
従来型のサイバー防御だけでは、もはや十分ではありません
エージェントは、ますます利用しやすくなっているオープンウェイトモデルを悪用し、長期にわたるサイバーオペレーションを実行できるようになりました。これを受けて、OpenAI では Defense Factory を構築しています。脆弱性を継続的に発見、検証、修正する自動化された防御オペレーションです。
Cloudflare(新しいウィンドウで開く)、Ramp(新しいウィンドウで開く)、Google(新しいウィンドウで開く) のチームも、このアプローチを模索しています。ここでは、私たち自身の Defense Factory を支えるアーキテクチャとプロセス、そしてその構築を通じて得た知見を共有します。
最新のフロンティアモデルが、本番環境にすでに存在する脆弱性を発見
最近実施したセキュリティスプリントでは、最新のサイバーモデルを使用して、OpenAI 全体の脆弱性を発見、検証、修正しました。250 人以上を動員し、インシデント対応と同等の緊急性をもって作業に取り組みました。
エージェントがエクスプロイト同士をつなぎ合わせられるようになりました
エージェントは、セッションをまたいで学習内容を保持し、システムに対する詳細な理解を深め、脆弱性同士を関連付けます。以前は実行不可能だった複雑な攻撃を、今では自律的に遂行できるようになっています。
エージェント群が攻撃の規模を何倍にも拡大させる
フリートで長時間稼働するエージェントは、人間が介在するセキュリティ対応で同じ脆弱性を発見し、修正できるよりもはるかに早く、より大規模に脆弱性を悪用できます。
マシンスピードでの脆弱性悪用
防御側は先行していますが、私たちは行動しなければなりません
防御側には、構造的な優位性が2つあります。防御側は、エージェントに自らのコードへの直接アクセスを与え、フロンティアモデルを利用することで、広く利用可能なオープンウェイトモデルを悪用する攻撃者に先んじることができます。
サイバー能力
時間
- フロンティア
- 防御側の能力
- 広く普及
継続的な防御を実装する
防御側の猶予
ここの先行できる時間が、防御側の猶予です。
Defense Factory
Defense Factory は、エージェントを中心に、脆弱性の発見と修正を継続的に行うオペレーションです。これにより、攻撃者がますます高性能になるオープンウェイトモデルを悪用して攻撃活動を加速させる中でも、防御側はその動きに遅れず対応できます。エージェントは既存のセキュリティツールやエンジニアリングツールを使用します。再利用可能なスキルによってエージェントが従うワークフローが定義され、隔離された再現可能な環境では、検出された問題を調査し、テスト済みの修正案をレビュー用に準備できます。チームはプロセスのより多くの部分を段階的に自動化し、引き継ぎを減らして、脆弱性の発見から修正までの時間を短縮します。
従来型セキュリティ
既存のツール。理想的には、MCP、CLI、または API を通じてエージェントがアクセスできるもの。
GitHub · GitLab
Snyk · Semgrep · Tenable
Jira · Linear · ServiceNow
Defense Factory
既存のツール同士をつなぎ、エージェントが継続的なワークフローの中で脆弱性を積極的に検出して修正できるようにします。
隔離された再現可能な環境 · Ona、Cloudflare、Modal
- Codex Desktop
- Codex CLI
- Codex Security CLI
セキュリティスキャン · 検出結果のトリアージ · 検出結果の修正
カスタムスキル
Astra · Sol · Terra · Luna
Daybreak Blue · Daybreak Red
継続的な防御のアーキテクチャ
Defense Factory は、脆弱性を再現し、修正が有効に機能することを検証する必要があります。そのためには、適切なコード、依存関係、サービスを備えた、再現可能で分離された開発環境が必要であり、さらに、エージェントが大規模かつ安全に作業できるようにするオーケストレーションとアクセス制御による支援も必要です。
コントロールプレーン
実行環境をスケーリングし、ポリシーとシークレットを一元管理します。
データプレーン
検出結果を検証するための、隔離された一時的な環境。
開発者向けシステム
エージェントが動作するために必要なツールを提供します。
状態とワークフロー
保護対象、エージェントが検出した内容、修正が必要な項目を把握できます。
セキュリティと監査
サイバーモデルを実行するエージェントを監視し、安全な実行と、機密性の高いコンテキストやデータへのセキュアなアクセスの確保を支援します。
Defense Factory が従来のセキュリティをどのように強化するか
横にスクロールして、Factory が追加する内容を確認してください。
| ワーク | よくあるボトルネック | Defense Factory が提供するもの |
|---|---|---|
| 探索 | 検出結果が調査待ちのまま滞留します。 | 検出結果によって自動調査が開始されます。 |
| トリアージ | 重複は優先順位を不明確にします。 | 重複項目を統合しました。悪用可能性をテスト済み。 |
| 所有権 | 検出結果は担当者の割り当て待ちです。 | すべての検出事項には、確認済みの担当責任者が設定されています。 |
| 修正 | エンジニアは調査を繰り返します。 | テスト済みのパッチは、エビデンスとともにレビュアーに届きます。 |
| 検証 | マージ済みの修正が未検証のままになります。 | デプロイ済みの修正は、独立して再テストされます。 |
OpenAI 全体でのセキュリティスプリントが、いかにして Defense Factory へと発展したか
新しいモデルの機能により、システムをより深く調査できるようになったため、セキュリティへの取り組みのペースと規模を拡大しました。社内でコードレッドを発令し、数百のシステムを対象とする連携スプリントに Security、Applied、Research の各チームを結集しました。
- 動員人数
- 250+250+
- 対象サービス領域
- 100+100+
「私たちは、インシデント発生時と同じ切迫感を持って防御態勢を強化しています。これは、事業継続に不可欠な業務を除き、すべてに優先される全社を挙げた取り組みです。スプリント終了後もこの緊急性を維持し、防御のテストと強化を続けていきます。」
そのスプリントは、当社の Defense Factory の出発点となりました。私たちは、システムをマッピングし、脆弱性を発見して検証し、担当者を割り当て、修正を確認し、実行のたびにシステムを改善する、継続的な防御ループの構築を進めています。
防御ループ
インベントリ
マップ, リンク, 更新
探索
スキャン, 分析, インポート
Dynamic validation(動的検証)
再現, テスト, 確認
所有権の割り当て
特定, 振り分け, フォローアップ
検証済みの修正
パッチ適用, デプロイ, 検証
- 01
インベントリ
マップ, リンク, 更新
- 02
探索
スキャン, 分析, インポート
- 03
Dynamic validation(動的検証)
再現, テスト, 確認
- 04
所有権の割り当て
特定, 振り分け, フォローアップ
- 05
検証済みの修正
パッチ適用, デプロイ, 検証
学習し、適応し、自律性を高める
学習し、適応し、自律性を高める
SECURITY.md は共有のシステムコンテキストを表し、ループ内の別のステップではありません。インベントリ、探索、動的検証、所有者の割り当て、検証済みの修復は、それぞれ既存のコンテキストを読み取り、得られた知見を反映します。各パスでは、すでに確立されているシステムマップ、所有権、調査の証拠、チェックを再利用するため、後続のパスでは最初からやり直すのではなく、変更点と未解決のリスクに集中できます。担当者は、影響の大きい変更をレビューし、デプロイ済みの修正を独立して検証します。パルスは、測定された進捗や削減量ではなく、コンテキストへの寄与を示します。
防御ループの構築から学んだこと
防御ループには適切な開発環境が必要です
再現可能な開発環境は、自律的な防御ループの基盤です。エージェントには、脆弱性の再現と修正のテストに必要なサービス、依存関係、構成を備え、大規模に自動プロビジョニングできる分離環境が必要です。これらの環境は一時的なものとし、実行ごとに新規作成され、その後は状態とともに破棄される必要があります。これにより、ある実行が次の実行に影響を及ぼさないようにします。
自律性は、手動の手順を起点として段階的に構築する必要がある
最初は小規模なバッチと人によるレビューから始め、結果への信頼が高まるにつれて、繰り返し発生する手作業のステップをなくしていきました。エージェントが変更を許可されている範囲とは切り離して、エージェントが実行できる作業量を拡大しました。エージェントが定型業務のより多くを担うようになるにつれ、人々は範囲や制約の設定、例外への対応、結果の確認へと軸足を移しました。
修正に着手する一方でシステムの棚卸しを実施
まず、私たちのシステムをマッピングすることから始めました。Codex は、既存の知見を共有バックログに集約する一方で、インベントリの作成を支援しました。初期の所有者検索は、依然として人が適切なチームを見つけることに依存していました。サービス情報と所有権情報を再利用可能な入力データに変換し、エージェントが課題のバッチをラベル付けして振り分けられるようにしました。曖昧なケースは人が対応します。これにより、承認済みの所有権割り当てが 90.6% に向上しました。 並行して、各チームはインベントリと所有権モデルが完成する前から、緊急の問題に取り組みました。初日には当社のシステム全体で緊急または優先度の高い問題を53件解決しました。
- ルーティング後に所有者が 対応を引き受けました
- 90.6%90.6%
エージェントトリアージの構築・改善
Codex は、検出結果のバッチを重大度の評価基準に照らして評価し、サービスおよびオーナーに関するコンテキストを追加しました。初期の重大度ラベルは範囲が広すぎ、分類はエージェントが受けた指示によってばらつきがありました。評価基準とプロンプトをバージョン管理し、繰り返し可能な評価を追加し、レビュアーが期待する優先事項と推論を記録しました。 人間スポットチェックは、優先順位の調整と、内容が不十分なレポートや重複したレポートの検出に役立ちました。また、重複排除が改善するまでルーティングを一時停止し、レビュー済みの小規模バッチから反復実行へと進み、検出結果の37%が重複する問題として特定されました。
- 重複と判定された 検出結果のうち
- 37%37%
実行時検証を繰り返し可能にしました
エージェントがコードを実行し、重大度を評価し、誤検知を除外するための隔離環境を構築することは、シグナルをノイズから切り分けるうえで重要なステップでした。しかし、環境セットアップが検証の制約となったため、繰り返し実行可能な一部のサービスから着手しました。 私たちは欠落している依存関係や構成の差異に対処し、再現しなかった検出結果と、適切に実行できなかったテストを区別できるようにしました。これらの改善により、検出結果の19.5%が実行時に再現され、動的検証後の誤検出率は0.81%でした。
- 動的検証後の 誤検知率
- 0.81%0.81%
パッチ適用の自動化を導入し、再利用可能なワークフローを構築しました
修復対応は 100% Codex ベースで行われ、エージェントがパッチを生成する一方で、私たちはルーティングと優先順位を改善しました。私たちはエージェントに、問題を再現し、稼働中のサービスに対して提案されたパッチをテストして、セキュリティ修正と通常の動作への影響の両方を確認できるように、再現可能な開発環境を提供しました。SECURITY.md ファイルと再利用可能なスキルに教訓を記録し、自動化された修正チェックと併せて、エージェントによるスキャンとトリアージを拡大しました。 フォローアップチェックの結果、マージ済みパッチとフリート全体にデプロイ済みの修正との間に差異があることが判明しました。小規模な試行の後、検証範囲を拡大し、修正が確認できた項目にコメントを投稿しました。一方で、デプロイ遅延をどのように考慮するかを検討していたため、自動再オープンは無効のままにしていました。
- ロールバックされた修正の割合
- 0.53%0.53%
技術ブログ記事は近日公開予定です
スキルとセキュリティワークフローに対する OpenAI のアプローチ
インベントリ
エージェントは、クラウドレコード、デプロイ構成、サービス所有権データを照合して資産インベントリに統合します。エージェントは、公開されているエンドポイントをコードや所有者に関連付け、証拠と不足点を保持して、より明確な範囲で検出を開始できるようにします。
図を詳しく見るには、横方向にスクロールしてください。
クラウドおよび資産レコード、ソースとデプロイの設定、サービスと担当者のデータが、再現可能な開発環境にまとめて取り込まれます。Codex は、提案された「インベントリの構築と更新」スキルと既存のサービス帰属情報の参照を使用して、資産インベントリを生成します。同じインベントリが Discovery への最初の入力です。インベントリの書き込みと更新スケジュールは、呼び出し元のワークフローで設定する必要があります。
入力
エージェントのワークフロー
再現可能な開発環境
出力
- サードパーティのプラットフォーム
- アーティファクト
- OpenAI 製品
- スキル / プラグイン
- 環境
探索
エージェントは、資産インベントリ、ソースコード、脅威モデル、セキュリティポリシーを使用して、セキュリティスキャンの指針を定め、攻撃経路を探索します。検出結果は既存の脆弱性レポートと統合され、候補となる脆弱性のプールにまとめられます。
図を詳しく見るには、横方向にスクロールしてください。
Inventory ワークフローからの資産インベントリ、ソース管理、脅威モデル、セキュリティポリシーが再現可能な開発環境にまとめて取り込まれ、Codex、Codex Security Scans、攻撃経路分析による探索に利用されます。脆弱性レポートはローカル探索を経由せず、「候補の脆弱性」に直接加わります。ディスカバリースキルは、決まった順序で進めるものではありません。
入力
エージェントのワークフロー
再現可能な開発環境
出力
- サードパーティのプラットフォーム
- アーティファクト
- OpenAI 製品
- スキル / プラグイン
- 環境
Dynamic validation(動的検証)
候補となる検出結果と実行可能なアプリケーションが与えられると、エージェントはコードを調査し、露出状況を再評価し、制御された環境で疑われる脆弱性の再現を試みます。確認済みの脆弱性について再現証拠を保存し、承認済みの課題を作成する前に重複を確認します。
図を詳しく見るには、横方向にスクロールしてください。
候補となる脆弱性とアプリケーションのセットアップは、再現可能な開発環境にまとめて取り込まれます。Codex は、検出事項のトリアージ & 検証と、重複排除 & 課題作成を使用します。トリアージと露出の再評価では、実行時の動作ではなくソースコードを検査します。検証済みの脆弱性には、再現を示す証拠が必要です。静的トレースのみでは、この出力要件を満たしません。反証済みおよび判定不能の結果は、その検出事項に関連付けられたままになります。Tracker への書き込みには承認が必要です。
入力
エージェントのワークフロー
再現可能な開発環境
出力
- サードパーティのプラットフォーム
- アーティファクト
- OpenAI 製品
- スキル / プラグイン
- 環境
所有権の割り当て
エージェントは企業固有のスキルを使用して、検証済みの検出事項を企業のコンテキスト、所有者記録、課題トラッカーと関連付け、所有者とエビデンスが明記された課題を生成します。
図を詳しく見るには、横方向にスクロールしてください。
Validated vulnerability、Instant messengers、Ownership records、Issue tracker がそろって、再現可能な開発環境に入ります。Codex は、カスタムの「Service and ownership attribution」スキルおよび「Issue labeling」スキルを使用して、「Assigned issue」を生成します。割り当ては、確認を意味するものではありません。
入力
エージェントのワークフロー
再現可能な開発環境
出力
- サードパーティのプラットフォーム
- アーティファクト
- OpenAI 製品
- スキル / プラグイン
- 環境
検証済みの修正
エージェントは修正を準備して独立して検証し、修復対象の選定を確認して、セキュリティ強化を提案します。人によるレビューと承認済みのデプロイの後、提案されたカスタムインテグレーションがデプロイされた修正を再テストし、検証エビデンスを記録します。
図を詳しく見るには、横方向にスクロールしてください。
割り当てられた課題、脆弱性の証拠、リポジトリの指示が、再現可能な開発環境にまとめて取り込まれます。Codex では、「Fix finding(指摘事項を修正)」、「Verify fix(修正の検証)」、「Review remediation pickup(修復対象の選定を確認する)」、「Security hardening(セキュリティ強化)」を使用できます。これらの機能は、必ず固定された順序で使用する必要があるものではありません。「Verify fix」では、人によるレビューと承認済みのデプロイの後に、パッチの検証と提案されたカスタム本番環境チェックを組み合わせます。デプロイ済みかつ検証済みの修復には、デプロイおよび検証のエビデンスが含まれます。不合格または結論が出ないチェックの場合、修復は未完了のままとなります。作業が承認されたことやチケットが移動したことは、修正済みであることを証明するものではありません。
入力
エージェントのワークフロー
再現可能な開発環境
出力
- サードパーティのプラットフォーム
- アーティファクト
- OpenAI 製品
- スキル / プラグイン
- 環境
継続的な防御を優先する
チームに概要を説明し、1 つのワークフローから始めて、Defense Factory の実現に向けて段階的に構築していきましょう。OpenAI で得た知見を、実践的なワークフロー、ツール、ガイダンスとともに引き続き公開していきます。
- 01
チームに説明する
ブリーフィング資料を使って Defense Factory の必要性を示し、方向性を定め、最初のワークフローについて合意します。
- 02
サイバーモデルの利用を申請する
認可された防御目的の業務のために OpenAI の高度なサイバーモデルへのアクセスを得るには、Daybreak に申請してください。
- 03
1つのワークフローを実行
Codex Security プラグインのスキルを使用して、脆弱性を検出し、検出結果を検証して、修正を準備します。
すでに OpenAI のお客様ですか?アーキテクチャについては、アカウントチームにご相談ください。
参考資料

Hugging Face のインシデント
Hugging Face のインシデント再構築の背景となった Black Hat 講演。
- インシデント分析エージェントによる侵入:技術的な時系列攻撃経路、調査、防御面での変更を含む、Hugging Face による不正侵入に関するフォレンジックに基づく説明。(新しいウィンドウで開く)
- インシデントの開示Hugging Face モデル評価のセキュリティインシデントモデル評価インシデントに関する OpenAI の説明、Hugging Face との対応、および評価セーフガードの変更。(新しいウィンドウで開く)
- 視点防御側の猶予防御側が行動を起こせる時間が限られている理由と、組織が AI を活用してサイバー防御を強化する方法。(新しいウィンドウで開く)
- プログラム更新サイバー防御の猶予が縮まる中での Daybreak の拡充Daybreak が高度なサイバーモデルへのアクセスを拡大し、防御担当者が適切な保護措置のもとでそれらを活用できるよう支援する方法。(新しいウィンドウで開く)
- ドキュメンテーションChatGPT LearnCodex Security プラグインCodex Security プラグインのインストール、リポジトリのスキャン、セキュリティ検出結果の確認に関するガイド。(新しいウィンドウで開く)