防御側に残された猶予は少なくなっています

防御側は先行していますが、私たちは行動しなければなりません

OpenAI のアプローチ

The Defense Factory

継続的な防御の構築

従来型のサイバー防御だけでは、もはや十分ではありません

エージェントは、ますます利用しやすくなっているオープンウェイトモデルを悪用し、長期にわたるサイバーオペレーションを実行できるようになりました。これを受けて、OpenAI では Defense Factory を構築しています。脆弱性を継続的に発見、検証、修正する自動化された防御オペレーションです。

Cloudflare(新しいウィンドウで開く)Ramp(新しいウィンドウで開く)Google(新しいウィンドウで開く) のチームも、このアプローチを模索しています。ここでは、私たち自身の Defense Factory を支えるアーキテクチャとプロセス、そしてその構築を通じて得た知見を共有します。

最新のフロンティアモデルが、本番環境にすでに存在する脆弱性を発見

最近実施したセキュリティスプリントでは、最新のサイバーモデルを使用して、OpenAI 全体の脆弱性を発見、検証、修正しました。250 人以上を動員し、インシデント対応と同等の緊急性をもって作業に取り組みました。

ピーク週を基準とした、選択された「緊急」および「高」の検出結果レポート(「完了」または「解決済み」とマーク済み)の完全な5週間分。完了として記録されていることは、デプロイ済みの是正措置が独立して検証されたことを示すものではありません。P0/P1 の修正P0/P1 の修正54631491535

エージェントがエクスプロイト同士をつなぎ合わせられるようになりました

エージェントは、セッションをまたいで学習内容を保持し、システムに対する詳細な理解を深め、脆弱性同士を関連付けます。以前は実行不可能だった複雑な攻撃を、今では自律的に遂行できるようになっています。

攻撃チェーンの例1 本の経路が、迷路の中で連続するノードをつないでいます。到達した各ノードによって次のノードが有効になり、それ以前のステップも接続されたままになります。これは概念図であり、インシデントの再現ではありません。

エージェント群が攻撃の規模を何倍にも拡大させる

フリートで長時間稼働するエージェントは、人間が介在するセキュリティ対応で同じ脆弱性を発見し、修正できるよりもはるかに早く、より大規模に脆弱性を悪用できます。

モデルとエージェントが速度重視へと収束する広く利用可能なモデルと長時間実行エージェントは、上部で接続されています。2 本のトレースがマシンスピードエクスプロイテーションへと下降し、到達するにつれて上から下へと満たされていきます。ラベルは常に表示されたままです。

防御側は先行していますが、私たちは行動しなければなりません

防御側には、構造的な優位性が2つあります。防御側は、エージェントに自らのコードへの直接アクセスを与え、フロンティアモデルを利用することで、広く利用可能なオープンウェイトモデルを悪用する攻撃者に先んじることができます。

サイバー能力

フロンティアに到達し、その後も歩調を合わせるサイバー能力は上に行くほど高くなり、時間は右に進みます。フロンティアモデルと広範に普及したモデルの能力は、ますます速いペースで向上しています。継続的な防御が導入されるまで、防御能力は横ばいのままです。その後、S字カーブを描いて上昇します。緩やかな進展、急速な改善を経て、最後はフロンティアの曲線に滑らかに合流します。防御曲線とフロンティア曲線は合流し、その後は同じ上昇軌道をたどります。導入済みの防御能力と広く普及した能力の間にある青色の領域が、防御側に開かれた好機です。ペースを維持するには、継続的な取り組みが必要です。これらは説明用の推移であり、実測結果や予測ではありません。

時間

  • フロンティア
  • 防御側の能力
  • 広く普及

継続的な防御を実装する

防御側の猶予

ここの先行できる時間が、防御側の猶予です。

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 が提供するもの
探索検出結果が調査待ちのまま滞留します。
検出結果によって自動調査が開始されます。
トリアージ重複は優先順位を不明確にします。
重複項目を統合しました。悪用可能性をテスト済み。
所有権検出結果は担当者の割り当て待ちです。
すべての検出事項には、確認済みの担当責任者が設定されています。
修正エンジニアは調査を繰り返します。
テスト済みのパッチは、エビデンスとともにレビュアーに届きます。
検証マージ済みの修正が未検証のままになります。
デプロイ済みの修正は、独立して再テストされます。

新しいモデルの機能により、システムをより深く調査できるようになったため、セキュリティへの取り組みのペースと規模を拡大しました。社内でコードレッドを発令し、数百のシステムを対象とする連携スプリントに Security、Applied、Research の各チームを結集しました。

動員人数
250+
対象サービス領域
100+

「私たちは、インシデント発生時と同じ切迫感を持って防御態勢を強化しています。これは、事業継続に不可欠な業務を除き、すべてに優先される全社を挙げた取り組みです。スプリント終了後もこの緊急性を維持し、防御のテストと強化を続けていきます。」

— Thibault Sottiaux 氏、OpenAI のコアプロダクトおよびプラットフォーム責任者

そのスプリントは、当社の Defense Factory の出発点となりました。私たちは、システムをマッピングし、脆弱性を発見して検証し、担当者を割り当て、修正を確認し、実行のたびにシステムを改善する、継続的な防御ループの構築を進めています。

防御ループ

  1. 01

    インベントリ

    マップ, リンク, 更新

  2. 02

    探索

    スキャン, 分析, インポート

  3. 03

    Dynamic validation(動的検証)

    再現, テスト, 確認

  4. 04

    所有権の割り当て

    特定, 振り分け, フォローアップ

  5. 05

    検証済みの修正

    パッチ適用, デプロイ, 検証

学習し、適応し、自律性を高める

SECURITY.md共有コンテキスト

SECURITY.md は共有のシステムコンテキストを表し、ループ内の別のステップではありません。インベントリ、探索、動的検証、所有者の割り当て、検証済みの修復は、それぞれ既存のコンテキストを読み取り、得られた知見を反映します。各パスでは、すでに確立されているシステムマップ、所有権、調査の証拠、チェックを再利用するため、後続のパスでは最初からやり直すのではなく、変更点と未解決のリスクに集中できます。担当者は、影響の大きい変更をレビューし、デプロイ済みの修正を独立して検証します。パルスは、測定された進捗や削減量ではなく、コンテキストへの寄与を示します。

防御ループの構築から学んだこと

防御ループには適切な開発環境が必要です

再現可能な開発環境は、自律的な防御ループの基盤です。エージェントには、脆弱性の再現と修正のテストに必要なサービス、依存関係、構成を備え、大規模に自動プロビジョニングできる分離環境が必要です。これらの環境は一時的なものとし、実行ごとに新規作成され、その後は状態とともに破棄される必要があります。これにより、ある実行が次の実行に影響を及ぼさないようにします。

自律性は、手動の手順を起点として段階的に構築する必要がある

最初は小規模なバッチと人によるレビューから始め、結果への信頼が高まるにつれて、繰り返し発生する手作業のステップをなくしていきました。エージェントが変更を許可されている範囲とは切り離して、エージェントが実行できる作業量を拡大しました。エージェントが定型業務のより多くを担うようになるにつれ、人々は範囲や制約の設定、例外への対応、結果の確認へと軸足を移しました。

  • 修正に着手する一方でシステムの棚卸しを実施

    まず、私たちのシステムをマッピングすることから始めました。Codex は、既存の知見を共有バックログに集約する一方で、インベントリの作成を支援しました。初期の所有者検索は、依然として人が適切なチームを見つけることに依存していました。サービス情報と所有権情報を再利用可能な入力データに変換し、エージェントが課題のバッチをラベル付けして振り分けられるようにしました。曖昧なケースは人が対応します。これにより、承認済みの所有権割り当てが 90.6% に向上しました。 並行して、各チームはインベントリと所有権モデルが完成する前から、緊急の問題に取り組みました。初日には当社のシステム全体で緊急または優先度の高い問題を53件解決しました。

    ルーティング後に所有者が 対応を引き受けました
    90.6%
  • エージェントトリアージの構築・改善

    Codex は、検出結果のバッチを重大度の評価基準に照らして評価し、サービスおよびオーナーに関するコンテキストを追加しました。初期の重大度ラベルは範囲が広すぎ、分類はエージェントが受けた指示によってばらつきがありました。評価基準とプロンプトをバージョン管理し、繰り返し可能な評価を追加し、レビュアーが期待する優先事項と推論を記録しました。 人間スポットチェックは、優先順位の調整と、内容が不十分なレポートや重複したレポートの検出に役立ちました。また、重複排除が改善するまでルーティングを一時停止し、レビュー済みの小規模バッチから反復実行へと進み、検出結果の37%が重複する問題として特定されました。

    重複と判定された 検出結果のうち
    37%
  • 実行時検証を繰り返し可能にしました

    エージェントがコードを実行し、重大度を評価し、誤検知を除外するための隔離環境を構築することは、シグナルをノイズから切り分けるうえで重要なステップでした。しかし、環境セットアップが検証の制約となったため、繰り返し実行可能な一部のサービスから着手しました。 私たちは欠落している依存関係や構成の差異に対処し、再現しなかった検出結果と、適切に実行できなかったテストを区別できるようにしました。これらの改善により、検出結果の19.5%が実行時に再現され、動的検証後の誤検出率は0.81%でした。

    動的検証後の 誤検知率
    0.81%
  • パッチ適用の自動化を導入し、再利用可能なワークフローを構築しました

    修復対応は 100% Codex ベースで行われ、エージェントがパッチを生成する一方で、私たちはルーティングと優先順位を改善しました。私たちはエージェントに、問題を再現し、稼働中のサービスに対して提案されたパッチをテストして、セキュリティ修正と通常の動作への影響の両方を確認できるように、再現可能な開発環境を提供しました。SECURITY.md ファイルと再利用可能なスキルに教訓を記録し、自動化された修正チェックと併せて、エージェントによるスキャンとトリアージを拡大しました。 フォローアップチェックの結果、マージ済みパッチとフリート全体にデプロイ済みの修正との間に差異があることが判明しました。小規模な試行の後、検証範囲を拡大し、修正が確認できた項目にコメントを投稿しました。一方で、デプロイ遅延をどのように考慮するかを検討していたため、自動再オープンは無効のままにしていました。

    ロールバックされた修正の割合
    0.53%

技術ブログ記事は近日公開予定です

インベントリ

エージェントは、クラウドレコード、デプロイ構成、サービス所有権データを照合して資産インベントリに統合します。エージェントは、公開されているエンドポイントをコードや所有者に関連付け、証拠と不足点を保持して、より明確な範囲で検出を開始できるようにします。

図を詳しく見るには、横方向にスクロールしてください。

クラウドおよび資産レコード、ソースとデプロイの設定、サービスと担当者のデータが、再現可能な開発環境にまとめて取り込まれます。Codex は、提案された「インベントリの構築と更新」スキルと既存のサービス帰属情報の参照を使用して、資産インベントリを生成します。同じインベントリが Discovery への最初の入力です。インベントリの書き込みと更新スケジュールは、呼び出し元のワークフローで設定する必要があります。

入力

エージェントのワークフロー

再現可能な開発環境

出力

  • サードパーティのプラットフォーム
  • アーティファクト
  • OpenAI 製品
  • スキル / プラグイン
  • 環境

継続的な防御を優先する

チームに概要を説明し、1 つのワークフローから始めて、Defense Factory の実現に向けて段階的に構築していきましょう。OpenAI で得た知見を、実践的なワークフロー、ツール、ガイダンスとともに引き続き公開していきます。

  1. チームに説明する

    ブリーフィング資料を使って Defense Factory の必要性を示し、方向性を定め、最初のワークフローについて合意します。

  2. サイバーモデルの利用を申請する

    認可された防御目的の業務のために OpenAI の高度なサイバーモデルへのアクセスを得るには、Daybreak に申請してください。

  3. 1つのワークフローを実行

    Codex Security プラグインのスキルを使用して、脆弱性を検出し、検出結果を検証して、修正を準備します。

すでに OpenAI のお客様ですか?アーキテクチャについては、アカウントチームにご相談ください。

参考資料

Hugging Face のインシデント

Hugging Face のインシデント再構築の背景となった Black Hat 講演。

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