Google Chrome AI搭載 セキュリティ脆弱性修復

Googleは、Chromeブラウザの脆弱性ライフサイクル全体にわたって大規模言語モデル（LLM）を統合し、セキュリティバグの発見と修正を拡大しました。Chrome Stableのリリースマイルストーン149および150では、Googleは1,072件のセキュリティバグを修正し、この数は直前の23マイルストーンで修正されたセキュリティバグの総数を上回ります。

AI駆動の脆弱性発見

Googleは、従来のファジングでは見逃す可能性のある脆弱性を特定するために、多層的なAIアプローチを使用しています。これには、専門のエージェントと包括的なナレッジベースの活用が含まれ、検出精度の向上と誤検知の削減を実現します。

発見パイプライン

  • Agent Harnesses: GoogleはGemini搭載エージェントを利用して、Chromeコードベース全体をスキャンしています。このアプローチにより、13年以上コードベースに存在していたサンドボックス脱出脆弱性が特定されました。
  • Knowledge Integration: LLMの推論能力を初期のトレーニングデータを超えて拡張するため、Googleはこれまでに特定されたすべてのCVEとChromeの全Git履歴を含むナレッジベースを構築しました。
  • Contextual Guidance: チームはモデルが信頼境界や脅威モデルを理解できるように、SECURITY.md ファイルの使用を推奨しています。専用の「critic」エージェントがこれらのファイルを取り込み、検出結果を検証します。
  • Model Interoperability: システムはオープンウェイトモデルとプロプライエタリモデルの両方をサポートし、異なるアーキテクチャの独自の強みを活かします。

安全ガードレール

AIが予期せぬ動作をしないように、Googleは厳格な環境制御を実施しています：

  • Isolated Execution: AIは、一般的なインターネットアクセスが遮断されたロックダウンされたマシン上で、静止状態のソースコードのみを解析します。
  • Network Interception: すべてのネットワーク要求は、発信アプリケーションと宛先に基づく厳格な許可リストを通じてインターセプトおよびフィルタリングされます。
  • Restricted Access: サブエージェントはローカルシステムの変更や、指定されたソースコードディレクトリ外のファイルへのアクセスが禁止されています。

自動化されたトリアージと修正

発見されたバグの量が増加するにつれ、Googleは従来は1件のレポートにつき5〜30分かかっていた人間中心のトリアージから、ルールベースシステムとAIを組み合わせた自動化パイプラインへと移行しました。

四段階トリアージプロセス

  1. Noise Filtering: スパム、重複、基本的な脆弱性基準を自動的にチェックします。
  2. Reproduction: システムは影響を受けたOSやブラウザバージョン上で概念実証（PoC）を検証し、スタックトレースをレポートに添付します。
  3. Metadata Enrichment: AIは重大度評価を割り当て、明確化された重大度ガイドラインに基づきバグが最初に導入された時期を特定します。
  4. Automatic Assignment: 課題は適切なコンポーネントと担当者に自動的に割り当てられます。

マルチエージェント修正ワークフロー

Googleは、専門エージェントのループを用いて修正案の生成と検証を行います：

  • Fixing Agent: 課題のコンテキストに基づき、複数の候補修正を生成します。
  • Critic Agent: 候補修正の機能性とChromiumおよびGoogleのスタイルガイドへの準拠を評価します。
  • Test-Writing Agents: 人間の開発者が修正をレビューする前に、すべてのサポートプラットフォームと構成に対してテストを自動生成し、数週間に及ぶ手作業を削減する可能性があります。

「パッチギャップ」削減

「N-day」攻撃（修正が公開された後、ユーザーのマシンに適用される前に攻撃者がバグを悪用する）を緩和するため、Googleは配信ペースを加速しています。

  • Release Frequency: Googleは週2回のセキュリティリリースへのシフトを試行中で、主要マイルストーンは2週間サイクルへと移行しています。
  • Dynamic Patching: Googleは「ダイナミックパッチング」を研究しており、バックグラウンドの子プロセス（RendererやGPUなど）を実行時に更新されたバイナリに置き換えることで、ブラウザ全体の再起動を不要にします。
  • Auto-Restart Optimization: macOSでは、Chrome 150がアプリケーションが「ウィンドレス」状態（すべてのウィンドウが閉じられたバックグラウンドで実行中）のときに自動的に再起動し、アップデートを適用します。

長期的な構造的防御

Googleは、AIによるパッチ適用と、特にメモリ安全性に焦点を当てた脆弱性全体のクラスを排除する戦略を組み合わせています。

C++ 強化

  • MiraclePtr & MiracleObject: これらのツールはUse-After-Free（UAF）脆弱性を無効化するために使用されます。MiracleObjectはGPUメインスレッド上のUAF脆弱性の最大90％を無効化することを目指しています。
  • Spanification: Chromeはレガシーなポインタとサイズの構造をstd::span型に移行し、範囲外（OOB）エラーを排除しています。現在、一次コードの97％が厳格なunsafe-buffer警告でコンパイルされています。

Rust への移行

Googleは、画像コーデックやフォントスタックなどの高リスクコードセグメントを戦略的にRustに置き換え、コンパイル時のメモリ安全性保証を提供し、ランタイム緩和策やサンドボックスへの依存を削減しています。

コミュニティの視点と批判

Googleは大幅な生産性向上を報告していますが、技術コミュニティはAIへの依存に関していくつかの反論を提起しています：

「それらの自動修正のうち、どれだけが取り消されましたか？どれだけが新たなバグを導入しましたか？検出エージェントの誤検知率はどれくらいですか？この記事はうまくいった点の数は示していますが、うまくいかない可能性については何も示していません。」

他の批評家は、見つかったバグの急増はAIの成功というよりもC++の根本的な欠陥の症状であり、唯一の永続的な解決策はメモリ安全な言語への完全な移行であると主張しています。また、AIが古いバグを修正する際に新たなバグを導入する「ホワイト・ア・モール」効果や、Googleの内部AI能力が最終的にオープンソースやクラウドソーシングされたバグハンティングへのインセンティブを減少させる可能性についても懸念があります。

Sources