OpenAI、250人規模のセキュリティスプリントを継続的なAI防御ファクトリーへ転換
OpenAIは、同社のサイバーモデルが数百のシステムにまたがる脆弱性修正を支援したと説明し、継続的なエージェントベースの防御プログラムを開始した。
目次 · 11
OpenAIは、Codexと専門的なサイバーモデルを用いて、発見、トリアージ、修正、検証を支援し、数百のシステムにまたがる脆弱性の発見と修正に250人超の従業員を動員したと説明している。同社は現在、この社内セキュリティスプリントから発展したアーキテクチャと運用プロセスを公開し、得られたシステムを「防御ファクトリー（Defense Factory）」と呼んでいる。
この開示には、通常より具体的な運用結果が含まれている。OpenAIによると、チームはスプリント初日に緊急または高優先度の問題を53件クローズし、検出結果を担当者へ振り分ける際に90.6%の受諾率を達成した。また、検出結果の37%を重複として分類し、動的検証後の偽陽性率を0.81%まで低減したという。
これらの数値が示すのは社内の防御プログラムであり、外部侵害の公表ではない。OpenAIは影響を受けたサービスを特定しておらず、脆弱性の総数や深刻度分布、報告された各率の分母と測定期間もすべては公表していない。したがって、公開資料だけから同社の結果を独立して再現することはできない。この開示の重要性は、むしろ運用モデルにある。セキュリティ業務は、定期スキャンと人手による引き継ぎの連続ではなく、持続的なエージェントワークフローとして再編されている。
一、セキュリティスプリントは100を超えるサービス領域を対象とした
OpenAIは、当初の取り組みを、Security、Applied、Researchの各組織を集結させた社内の「コードレッド」と説明している。250人超が参加し、作業は数百のシステムを含む100を超えるサービス領域に及んだ。
スプリント開始時点で、OpenAIにはそれらのシステムの完全なマップがなかった。Codexは資産インベントリの作成を支援し、チームは既存のセキュリティ検出結果を共通バックログへ取り込んだ。サービス所有者データ、デプロイ構成、クラウド記録、ソースコード、公開エンドポイントを段階的に接続し、エージェントが各検出結果をどのチームへ送るべきか判断できるようにした。
OpenAIは、このプロセスで90.6%の所有者受諾率を達成したと報告している。人間のレビュー担当者は曖昧なケースの解決を継続する一方、インベントリ完成前にも緊急の修正を進めた。この並行アプローチにより、チームは初日に緊急または高優先度の問題を53件クローズできた。
エージェントは、深刻度ルーブリックに照らして検出結果も評価した。OpenAIによると、初期の分類は一貫性に欠け、モデルに与える指示に敏感だった。同社はこれを受け、プロンプトとルーブリックをバージョン管理し、再現可能な評価を追加し、レビュー担当者が想定する優先度と根拠を記録し、人手による抜き取り確認を維持した。
重複排除も明示的なゲートとなった。OpenAIは、このプロセスが改善されるまで自動振り分けを一時停止し、最終的に調査した検出結果の37%が重複であると判断した。単に報告を増やすエージェントシステムは、リスクを低減しないままセキュリティエンジニアの負担を増やしかねないため、これは重要である。
動的検証は、再現可能な脆弱性を静的解析のノイズから切り分けるために用いられた。エージェントには選択されたサービスの実行可能なバージョンが与えられ、管理された環境内で疑わしい問題の再現を試みた。OpenAIは、この段階後の偽陽性率を0.81%と報告しているが、検証済みサンプルの規模や構成は開示していない。
二、防御ファクトリーは5段階のエージェントループを採用する
防御ファクトリーは、単一のモデルや脆弱性スキャナーとして提示されているわけではない。既存のソース管理システム、セキュリティスキャナー、課題トラッカー、開発環境、企業固有のコンテキスト、AIエージェントを接続するリファレンスアーキテクチャである。
そのワークフローは、インベントリ、発見、動的検証、所有者割り当て、検証済み修正という、繰り返し実行される5段階で構成される。
インベントリエージェントは、クラウドリソース、デプロイ構成、ソースコード、公開エンドポイント、サービス所有者記録を照合する。次に発見エージェントが、そのインベントリを脅威モデル、セキュリティポリシー、ソースコード、SnykやWizなどのツールから取り込んだ検出結果と組み合わせる。出力は、確認済みの欠陥一覧ではなく、候補となる脆弱性のプールである。
動的検証では、エージェントが関連コードを調査し、実行可能なアプリケーション内で各候補の再現を試みる。OpenAIの仕様では、静的なトレースだけでは不十分であり、検証済みの脆弱性には再現の証拠が必要とされる。否定された検出結果と結論に至らない検出結果も記録に紐付けたままとし、トラッカーでの課題作成には承認が必要となる。
所有者エージェントは、検証済みの検出結果を資産インベントリ、コード所有者ファイル、コミット履歴、社内コミュニケーション、課題トラッカーと結び付ける。OpenAIは割り当てと受諾を区別し、自動で振り分けられたチケットが受諾済みの作業として扱われないようにしている。
最終段階では、Codexがパッチを作成し、再現可能な環境でその動作を確認する。人間によるレビューと認可済みのデプロイ後、別のチェックが本番環境の修正を再テストする。マージ済みのプルリクエストや移動済みのチケットは修正完了の証拠とはみなされず、検証に失敗した場合や結論が出ない場合は、問題はオープンのままとなる。
共有されたSECURITY.mdファイルは、サイクル間でシステム固有の知識を保持する。各パスは、そのコンテキストを毎回再構築するのではなく、マッピング、所有者情報、調査の証拠、過去の検証チェックを再利用できる。同社は、重大な変更には引き続き人間のレビューを行い、デプロイされた修正は独立して検証するとしている。
三、分離とアクセス制御もセキュリティ境界の一部である
OpenAIのアーキテクチャは、コントロールプレーンとデータプレーンを分離している。コントロールプレーンはワークロードのオーケストレーション、ポリシー適用、認証情報へのアクセスを管理する。データプレーンは、エージェントがアプリケーションの実行、脆弱性の再現、パッチのテストを行う隔離された開発環境を提供する。
これらの環境は一時的なものとして設計されている。各実行は新しい環境から開始され、その状態は後で破棄される。これにより、ある調査が別の調査を汚染するリスクを減らし、反復的な検証の信頼性を高める。
このアーキテクチャは、ソース管理、シークレットストレージ、アーティファクトレジストリ、モデルエンドポイントも組織のプライベートネットワーク内に配置する。資産インベントリと検出結果データベースはワークフローの状態を保持し、ホスト監視、インフラセキュリティ、エージェント監査システムがパイプライン全体の活動を監督する。
OpenAIは、自律性を段階的に高めたとしている。まず小規模なバッチと人間によるレビューから始め、結果の信頼性が高まるにつれて、繰り返し発生する手作業を取り除いた。エージェントに付与する権限は、実行できる分析作業の量とは分離して維持された。
この区別は、修正時に特に重要である。OpenAIは、スプリントのすべてのパッチをエージェントが生成し、修正を「100% Codexベース」と説明しているが、重大なレビューと認可済みのデプロイは引き続き人が担った。ロールバックされた修正の報告率は0.53%だったが、同社はその割合に相当するパッチの実数を公表していない。
後続チェックでは、修正がマージされることと、すべてのデプロイ済みシステムへ到達することの間にも隔たりがあることが判明した。OpenAIはデプロイ後の検証を拡張したが、修正失敗と通常のデプロイ遅延を区別する方法を確立する間は、自動再オープンを無効のままとした。
四、移転可能な成果は人員数ではなく検証パイプラインにある
OpenAIの中心的な主張は、攻撃者が同等のアクセスを得る前に、防御側はプライベートコード、デプロイコンテキスト、所有者記録、より強力なフロンティアモデルを利用できるというものだ。防御ファクトリーは、この優位性を発見から検証済み修正までのサイクル短縮へ転換するよう設計されている。
Cloudflareも別途、これに匹敵するマルチエージェントの脆弱性ハーネスについて説明している。そのパイプラインは、偵察、探索、敵対的検証、重複排除、依存関係追跡、パッチ準備のために別々のエージェントを使用する。生成された修正が本番環境に到達する前には人間の承認を必要とし、モデルの文章による評価を信頼するのではなく、再現可能なテストをゲートとして扱う。
この独立した実装は、基礎となるワークフローパターンを裏付けると同時に、そのコストも示している。Cloudflareによると、大規模スキャンには数時間を要し、50人から200人のワーカーのプールが必要で、運用上のボトルネックは欠陥の発見から修正のレビューと安全なデプロイへ移る。継続的なエージェント活動によって、アプリケーション所有者、信頼できるテスト環境、リリースエンジニアリング、セキュリティ上の判断が不要になるわけではない。
OpenAIの設計を検討する組織にとって、最も具体的な変化は手順上のものである。候補となる検出結果はエンジニアに届く前に重複排除と再現を行う必要があり、所有者は現行の運用記録に紐付ける必要があり、パッチは回帰チェックに合格しなければならず、修正はデプロイ後に検証しなければならない。これらのゲートがなければ、エージェントの追加は脆弱性の削減ではなく、レポート作成の加速につながるおそれがある。
基盤となるモデルへのアクセスも一律ではない。OpenAIが公開したアーキテクチャでは、Daybreak BlueおよびDaybreak Redのセキュリティモデルに加え、Astra、Sol、Terra、Lunaを含む汎用モデルが挙げられている。より許容範囲の広いサイバー能力は、Daybreakを通じて確認済みの防御担当者に提供され、より強力な本人確認、スコープ制御、監視、監督が適用される。
したがって、公開資料はリファレンスアーキテクチャと社内ケーススタディであり、あらゆる組織がOpenAIの結果を直ちに再現できる証拠ではない。OpenAIは性能指標とワークフローの詳細を提供しているが、そのシステムを従来のセキュリティプログラムと比較したり、検出カバレッジを独立して評価したりするには、脆弱性レベルのデータが十分ではない。
よくある質問
OpenAIは確認済みの外部侵害に対応していたのですか？
いいえ。OpenAIはこの作業を社内セキュリティスプリントと説明しており、防御ファクトリーの発表が新たな外部侵入に関するものだとは述べていない。
防御ファクトリーは何をしますか？
資産インベントリ、脆弱性の発見、実行時検証、所有者への振り分け、パッチ生成、デプロイ後の検証を、繰り返し実行するエージェント支援ワークフローで接続する。
AIエージェントは人間の承認なしに修正をデプロイしましたか？
OpenAIによると、Codexがパッチを生成したが、重大な変更は引き続き人間のレビューとデプロイ承認の対象だった。その後、本番環境の修正は独立して再テストされた。
OpenAIは脆弱性を何件発見しましたか？
OpenAIは総数を公表していない。初日に緊急または高優先度の問題を53件クローズしたと報告しているが、検出結果の完全な件数や深刻度分布は開示していない。
どの組織でも同じサイバーモデルを使用できますか？
自動的には使用できない。OpenAIは認可された防御担当者にDaybreak経由での申請を案内しており、より高性能または許容範囲の広いサイバーツールへのアクセスは、検証、スコープ制御、監督に左右される。
参考ソース
Share
この記事を共有
