最新AI「ミュトス」を使えても「バグマゲドン」に？　Firefox開発元に学ぶセキュリティ対策（4/5 ページ）

公開 2026年05月28日 12時00分

[ITmedia]

印刷する連載新着通知を受け取る

　19年に公開した「Grizzly」というブラウザ・ファジング用フレームワークを中核に、検出したクラッシュを自動で分類・整理する「FuzzManager」サーバ、再現の難しいバグでも実行を記録・再生できる「Pernosco」、テストケースを最小化する自動ツール群といった一連のツールが、長年の運用のなかに組み込まれている。

　加えて、24年に本番投入されたスナップショット・ファジングという新しい手法もある。これは前述のサンドボックス・エスケープを効率的に探索する技術で、Mozillaのレポートでも、AIハーネスと並ぶ重要な手法として「このギャップを埋める新しい手法の開発で一定の成果を上げてきた」と言及している。

　要するにMozillaは、「クラッシュを再現可能なバグレポートに変換する自動化」を10年以上磨き続けてきた。AIハーネスが出した仮説の検証結果を、この自動化の入口に流し込むだけで十分だったのだ。

2）多層防御アーキテクチャ

　なぜここで防御アーキテクチャの話が出てくるのか。AIハーネスが吐き出す脆弱性候補は、放っておけば「どれもクリティカルに見える」という状態に陥りやすい。これを月数百件規模で実際の修正リリースまで運ぶには、「すでに設計で吸収済みで実害につながらないもの」と「コード修正が必要なもの」を切り分ける枠組みが必要だ。

　Firefoxの場合、この切り分けの軸を提供したのが、過去数年で積み上げてきた多層防御の各層だった。

　まずは、Mozillaが21年から段階的に展開し、Firefox 96でデフォルト有効化したサイト分離（Project Fission）だ。これはブラウザ内で開いている各Webサイトを、それぞれ独立したOSプロセスに分けて描画する仕組みで、1つのサイトに脆弱性があって攻撃者に突かれても、被害が他のサイトのデータに波及するのを防げる。

　次に、21年のFirefox 95で導入した「RLBox」。Firefoxは内部でフォント描画やスペルチェック、音声・画像処理などのためにC言語製の高速ライブラリを多数利用しているが、これらは古くから脆弱性の温床として知られてきた。RLBoxは、こうしたライブラリを隔離する仕組みで、ライブラリ側に問題があってもFirefox本体には波及しない設計になっている。

　22年のFirefox 100で本格化した「Win32k Lockdown」は、Webサイトを描画する必要最小限の特権を持つプロセスから、Windowsのカーネルの一部APIに直接アクセスできなくする仕組みだ。このAPIは過去にサンドボックス脱出の経路として頻繁に悪用されてきたため、遮断することで攻撃者の権限昇格を妨げる。

　さらに同じ頃、親プロセスのプロトタイプ凍結（オブジェクトの原型となるプロトタイプの変更を禁止し、外部コードによるプロパティ改ざんや振る舞いの差し替えを防ぐ防御策）も実施し、「プロトタイプ汚染」と呼ばれる古典的な権限昇格手口を設計的に封じた。

ハーネスが「発見できなかったバグ」を観察

　Mozillaのレポートから得られる重要な知見の一つが、この防御アーキテクチャに関する解説だ。Mozillaによると、AIハーネスが「発見できなかったバグ」、より正確には「発見しようとして既存の防御層に阻まれた経路」を観察できたという。

　ハーネスの動作ログを監査したところ、AIモデルが脆弱性を見つけようと多種多様な攻撃経路を試みているなかに、プロトタイプ汚染を経由して親プロセスへ侵入しようとする試行が何度も含まれていた。その試行は、いずれも先に述べたプロトタイプ凍結によって阻まれていた。

　「過去のハードニング作業からの直接的なペイオフを観測することは、より多くのバグを発見・修正することよりも報われた」（Mozilla）

　これは単なる感慨ではない。多層防御の存在は、AIが大量に吐き出した発見を「設計で吸収済み」と「コード修正が必要」に仕分けるための座標軸として機能した。逆にこの座標軸がない組織にAIハーネスを動かすと、全ての発見が「クリティカル」扱いになり、優先度判定が崩壊する。Mozillaはトリアージの座標軸そのものを、5～7年前から準備していたということになる。

3）出荷力

　最後が「バグをさばける組織体制」だ。Mozillaは「100人を超えるエンジニアがこの取り組みにコードで貢献した」としている。修正コードの執筆、レビュー、テスト、リリース管理といった多くの作業に対して、100人超のチームが動いて初めて月423件の修正を実現したわけだ。

月423件の修正を実現

　加えてMozillaは、「Bugzilla」というオープンな課題追跡基盤、内部発見バグをまとめてCVE（脆弱のデータベース）を発行する「rollup CVE」運用、公開された重大度評価基準を整備している。

　前述の通り、MozillaはFirefox 150で発見した脆弱性271件のうち、180件をsec-high、80件をsec-moderate、11件をsec-lowに分類している。大量の脆弱性に対しても正確にレベル分けし、優先順位を決められたのは、標準化された分類と管理の仕組みがあるからだ。

　多くの組織は「第1層がボトルネック」と誤認し、フロンティアAIモデルのアクセス確保を目標に据えがちだ。しかし実際のボトルネックは第3層にあることが多い。アクセスを得ても、大量に発見される脆弱性を裁く体制がボトルネックなら、組織は「発見したけれど直せないバグの山」を抱えることになる。

　業界の専門家の間では、近頃「バグマゲドン（Bugmageddon）」という言葉がささやかれるようになっている。コンピュータやプログラムの脆弱性を意味する「バグ」と、聖書で描かれる最終戦争「ハルマゲドン」を組み合わせた造語で、「AI支援による脆弱性発見の前例のない急増が、修正側のキャパシティーを超え、サイバーセキュリティに未曾有のリスクをもたらす」という意味だ。

　企業は目前に迫るバグマゲドンの脅威を正しく捉え、対処しなければならない。