Firefoxの423件の修正が浮き彫りにするメンテナー不足

2026年4月、MozillaはFirefoxのセキュリティ修正423件を報告した。前年の31件から増加しており、モデル支援の監査がFirefoxに通常寄せられるペースを上回る速度でバグを見つけていた時期でもあった。

自動化された調査結果を修正へ変えるには、なお検証、協調的な開示、パッチレビュー、リリースエンジニアリングが必要である。

独立した監査がFirefoxの従来の報告ペースを上回った

Mozillaによると、Claude Opus 4.6は100件超のFirefoxバグを発見した。期間は1月の2週間で、重大度の高い問題14件を含む。Mozillaはこれを、Firefoxに通常2カ月超かけて寄せられる件数より多いとしている。OpenAIも別途、Daybreak Red顧客への限定提供を準備する中で、GPT-6 Cyberが81件超の新規Firefox脆弱性を発見したと述べた。これらは別個に報告された監査であり、未修正の個別欠陥を合算した件数ではない。

Cloudflareも、AnthropicのMythos Previewを自社の50超のリポジトリでテストし、脆弱性探索に使ったハーネスを説明した。Mozilla、OpenAI、Cloudflareにとって、モデル支援の反復的な検査を行うのに共通の研究プログラムは必要なかった。それぞれ守るべきコードがあり、それを大規模に調べられるツールへのアクセスがあった。

OpenAIの集計には重要な限界がある。同社の報告は、Firefoxの欠陥が実際に悪用されたこと、すべてが同程度に深刻だったこと、あるいはMozillaが修正に要する期間を示すものではない。OpenAIは当初、GPT-6 CyberをDaybreak Red顧客に限定していたため、その結果は同じ能力が広く利用可能だったことを示さない。ただし、ブラウザのメンテナーが慣例的なペースではなく、まとまった件数の報告を受け取る準備をしなければならない理由は示している。

Mozillaは報告件数だけでなく、リリースした修正のペースも引き上げた

Mozillaは、Mythos Previewへの早期アクセスで特定した脆弱性の修正271件をFirefox 150に組み込んだ。その後、Mythos Previewと他のAIモデルが、前年の31件に対し、4月にFirefoxのセキュリティ修正423件を特定しリリースする助けになったと報告した。271件の修正は、このより広い4月の集計に含まれる。両方の数字を足せば、リリース作業を二重計上することになる。

Mozillaの4月のリリースは、AIがボトルネックを単に下流へ移すだけだという見方を複雑にする。同社チームは、この移行を恒久的な不安定化ではなく困難なものと位置付けた。この比較からは、423件すべての重大度も、すべてのプロジェクトがMozillaのワークフローを再現できるかも分からない。

他の開発者も修復を能力の一部として扱っている。OpenAIとParadigmは、スマートコントラクトの脆弱性を検出、悪用、修正するエージェントを評価するためにEVMbenchを設計した。Microsoftは、欠陥の修正を目的とするエージェント型システムとしてProject Perceptionを導入した。いずれの発表もFirefoxの成果を測定するものではないが、セキュリティ作業の有用な単位を最初のバグ報告より先に置いている。

非公開開示がもたらすのは、公開情報ではもはや得られない時間だ

Anthropicの研究者は、Mythos Previewが公開済みの脆弱性を、数週間ではなく数時間で動作するエクスプロイトに変えられると述べた。この主張は既知の欠陥に関するものであり、攻撃者がFirefoxに対してMythosを使った証拠ではない。それでも、開示の遅延が何のためにあるかを変える。メンテナーには、報告を再現し、重大度を評価し、影響を受ける関係者と調整し、修正をリリースするための保護された時間が必要になる。

GitHubは2023年、研究者がオープンソースのメンテナーに秘密裏に連絡できるよう、非公開の脆弱性報告を一般提供した。公開済みの欠陥を見つけることも悪用することも速くなるほど、この経路の重要性は増す。ただし、非公開の受信箱だけでは、パッチのレビューも、ユーザーが安全に受け取れる時点の判断もできない。

NISTは2025年、National Vulnerability Databaseで25,000件超の脆弱性バックログを抱えた。これは2017年の従来の最高値のおよそ10倍だった。NISTのカタログ化の待ち行列はMozillaのパッチ待ち行列ではない。発見の増加は、人が運用する複数の異なるシステムへの圧力を高めうる。そして一つの待ち行列を解消しても、他の待ち行列は解消しない。

小規模な依存関係はMozillaのリリースチームを借りられない

XZ Utilsのバックドアは2024年、十分に支援されていないオープンソース開発者への負担が生むセキュリティリスクに注目を集めた。AI支援の監査は別の負担を加える。メンテナーは、それを検証する時間が増えないまま、もっともらしい報告をより多く受け取るかもしれない。Linux Foundationによると、Anthropic、Amazon、Google、Microsoft、OpenAIは、自由・オープンソースのメンテナーがAI生成のセキュリティ調査結果を扱うのを支援するため、$12.5 millionの助成金を拠出した。この助成金は、スキャンの後に誰かが作業をしなければならないことを認めている。しかし、すべての依存関係が今や十分な能力を備えたことを示すものではない。

低品質な自動投稿も、本物の欠陥のために充てられるべきバグバウンティのレビュアーの注意を消費しうる。小規模プロジェクトは、リリース判断を下す前に、再現可能な脆弱性ともっともらしい誤報を見分けなければならない。モデルへのアクセス拡大はこの作業を助けるかもしれないが、アクセス自体が説明責任を負うメンテナーを生み出すわけではない。

ブラウザ連合は信頼判断を共有できても、パッチ作業は共有できない

Mozilla、Google、Microsoft、Cloudflareは、正当な人間またはボットのWebトラフィックと不要なリクエストを区別するため、Private Access Control Tokensで提携した。PACTが扱う問題はFirefoxの脆弱性修正とは異なる。これは、ブラウザのセキュリティも自動化された活動に関する共通ルールに依存することを示す。一方で各プロジェクトは、自らが管理するコードとリリースについて責任を負い続ける。

Mozillaの4月の修正423件は、モデル支援による発見が加速しても、ブラウザチームはリリースパイプラインを拡張できることを示す。小規模な依存関係は、モデルがバグを見つけたというだけでそのパイプラインを借りられない。防御側も攻撃側も探索を自動化できる限り、決定的な資源は、非公開で検証済みの報告を安全なリリースへ変えるメンテナーの時間である。