OpenAIは、サイバーセキュリティ製品「Daybreak Red Team」と「Daybreak Defense Factory」の詳細を公開した。Webアプリケーション向けのDaybreak Red Teamは、攻撃経路や修正の有効性を検証する製品で、現在は早期アクセスの登録を受け付けている。一方、Daybreak Defense Factoryは、Red Teamや既存のセキュリティツールが発見した問題を分析し、開発者がレビューできるコード修正案の作成を支援する。
脆弱性を発見することと、修正によって問題が解消されたことを確認するのは、それぞれ異なる作業だ。OpenAIは両製品を通じて、攻撃経路の検証から修正案の作成、人によるレビュー、コードのマージ後の再検証までを一貫して扱う仕組みを示した。ただし、Defense Factoryは研究プレビューの段階にあり、継続監視についても、設定した検査範囲や実行条件によって結果の意味が変わる点に注意が必要だ。
AIエージェントがWebアプリの脆弱性を検証し、修正後も再確認
Daybreak Red Teamは、許可された環境で攻撃経路を検証するペネトレーションテストを、Webアプリケーション向けに実施する製品だ。OpenAIによると、複数のAIエージェントが連携し、ソースコードやアプリケーションの構造を分析しながら、攻撃可能な経路を探索して脆弱性を検証する。単にコード内の疑わしい箇所を指摘するだけでなく、その問題が実際のアプリケーションの動作にどのような影響を及ぼすかを確かめる設計となっている。
既存のセキュリティツールや外部から寄せられた報告も検証対象にできる。コードスキャナーの検出結果、バグ報奨金プログラムを通じた報告、脆弱性開示によって寄せられた情報を調査し、得られた証拠を修正の優先順位付けに活用するという。さらに、パッチによって攻撃を防げるようになったかを確認し、アプリケーションの更新後にも検証を繰り返せると説明している。
こうした仕組みを理解するには、脆弱性の可能性を指摘する従来のスキャナーと、その指摘が実際に悪用可能かを調べる作業の違いが重要になる。OpenAIは既存の「Codex Security」についても、スキャナーの検出結果をリポジトリ固有の調査と検証によって補完する仕組みだと説明している。入力データやコードの実行経路、既存の防御策を調べ、指摘に対応する必要があるか、対象外なのか、追加の審査が必要なのかを判断するという。調査対象には、GitHubのコードスキャンやDependabot、セキュリティアドバイザリーのほか、JiraやLinearで管理されている報告も含まれる。
今回の発表は、これらの機能がすべて新たに登場したというより、攻撃経路の検証とコード修正を連携させる仕組みを、2つの製品として提示したものといえる。ただし、公開されている検証機能の説明はOpenAI自身によるものであり、第三者が実施した独立した性能評価とは区別する必要がある。
脆弱性の検証結果から、人がレビューできる修正案を作成
Daybreak Defense Factoryは、Red Teamや既存のセキュリティツールが発見した問題を受け取り、コード内の脆弱性を分析して修正パッチを作成する。開発者はCodexに追加情報を与え、検証結果を確認しながら修正案を調整できる。最終的なコードへの反映は自動的に確定するのではなく、エンジニアによるレビューとテストを経て判断する仕組みだ。
公式ドキュメントによると、問題の修正を指示すると、パッチの生成処理がバックグラウンドで実行される。開発者は提案されたコードの差分と、修正内容を検証する「Patch checker」の結果を確認し、GitHub上に下書きのプルリクエストを作成できる。その後、人がコードをレビューしてテストを実施し、マージ後のコードでも元の攻撃経路が機能しなくなったことを確認してから、修正済みとして扱う。
脆弱性の調査では、検出の根拠となった証拠や原因、攻撃経路を確認できる。修正案を評価する際には、変更されたコードだけでなく、その変更が脆弱性の原因にどう対応しているか、Patch checkerが何を検証したかも参照できる。重要なのは、修正案が作成された段階と、修正後のコードで問題が解消されたことを確認する段階を区別することだ。
OpenAIは、安全かつ実用的な場合には問題を再現し、変更範囲を限定したパッチと検証結果を用意すると説明している。実施可能であれば、修正前には失敗し、修正後には成功する回帰テストも追加する。一方、安全で信頼できるテストを作成できない場合には、確認できなかった事項を記録する方針だ。エンジニアはコードの差分だけでなく、再現できた問題や未検証の項目も踏まえて、修正を採用するか判断することになる。
また、修正の評価では、攻撃を防ぐだけでなく、正当な操作が引き続き機能するかも確かめる必要がある。公式ドキュメントに掲載されたエクスポート機能の説明例では、プロジェクトへの所属確認が欠けている処理に対し、別のプロジェクトからの不正な要求を拒否するテストと、適切な権限を持つ利用者のエクスポートを許可するテストの両方を確認するよう示している。不正な要求を拒否できても、正当な処理まで止めてしまえば適切な修正とはいえない。この例は修正の妥当性を判断する手順を説明したものであり、実際の導入効果を測定した結果ではない。
継続監視では何をどこまで検査できるのか
脆弱性の検査には、リポジトリを一度だけ調べる単発検査、新しいコミットを対象とする継続監視、設定した間隔で検査を繰り返す定期スキャンがある。それぞれ検査対象と実行のタイミングが異なるため、継続監視を有効にしただけで、すべてのコードが毎回検査されるわけではない。OpenAIの公式導入手順に基づき、各方式の違いを整理すると次のようになる。
| 検査方式 | 主な対象 | 検査のタイミング |
|---|---|---|
| 単発のリポジトリ検査 | 既定ブランチの現行コード | 検査を開始したとき |
| 新コミットの継続監視 | 既定ブランチへの新しいコミット | 新たなコミットに応じて実行 |
| 定期スキャン | 既定ブランチ | 設定したスケジュールに従って再検査 |
注：現行の公式仕様に基づく整理。検査対象はリポジトリ全体のほか、特定のフォルダーやファイルに限定することもできる。
新しいコミットを監視する方式と、既定ブランチを定期的に再検査する方式では、検査を実行する条件も確認範囲も異なる。継続監視では過去の変更をどこまでさかのぼるかも設定できるが、新しいコミットの検査結果だけを見て、既存コード全体が毎回確認されたと判断することはできない。検査結果を評価する際には、対象として設定したコードの範囲と、実際に検査された範囲を確認する必要がある。
また、検査が途中で失敗したり、予定より早く終了したりした場合、公式手順では実際に検査できた範囲を確認するよう求めている。OpenAIによれば、大規模なリポジトリではスキャンに数時間かかることもあるという。検査対象の広さや処理の完了状況を確認せず、脆弱性の報告がないことだけを理由に、安全性が十分に確認されたと判断することはできない。
早期アクセスの提供条件と、今後確認すべき性能
Daybreak Red Teamについて、OpenAIは隔離環境と「Guardian」による審査を用いて検証範囲を制御し、AIエージェントがアクセスできるアプリケーションや接続先を制限すると説明している。ただし、製品ページではGuardianの具体的な判断基準や、危険な操作をどの程度正確にブロックできるかまでは明らかにしていない。実際の導入にあたっては、検査を許可する環境や接続先を明確に定めることが重要になる。
一方、Daybreak Defense Factoryの公式導入手順では、対応するChatGPTワークスペースにプレビュー版プラグインをインストールする。クラウド上のスキャン処理はCodex cloudで実行され、利用を開始する各ユーザーには個人のGitHub接続が必要となる。現時点ではワークスペース単位のGitHub接続には対応していない。検査対象はリポジトリ全体に加え、特定のフォルダーやファイルに限定することも可能だ。
Daybreak Red Teamは早期アクセスへの関心登録を受け付けているが、登録しただけで利用が保証されるわけではない。Daybreak Defense Factoryも研究プレビューとして案内されており、一般提供に向けた条件はまだ明らかになっていない。また、OpenAIの公式イベント案内では、製品へのアクセス申請とモデルへのアクセス申請が別々に設けられている。高度な認可済みのセキュリティ研究や検証などに使用する「Daybreak Red」については、別途承認と安全対策が必要だという。
現時点で公開されている製品情報からは、Daybreak Red Teamの脆弱性検出率や誤検知率、第三者が同一条件で実施した性能比較の結果を確認できない。統一的な料金体系や一般提供の開始日、日本向けの個別条件も確定していない。導入を評価する際には、まず検査対象と実際に確認できた範囲を明らかにし、修正後のコードで攻撃経路が遮断され、正当な処理が維持されていることを証拠に基づいて確認する必要がある。今後は、こうした検証の実効性を示す定量的な結果と、正式な提供条件の公表が注目される。
