Google、AIで6月に過去2年分を上回るChromeのバグを修正

 (blog.google)
1 ポイント 投稿者 GN⁺ 2 시간 전 | 1件のコメント | WhatsAppで共有
  • ChromeはGeminiベースのエージェントで脆弱性の発見から分類・修正・配布・アップデート適用までを自動化し、Chrome 149と150で、直前の23マイルストーンを合計した数を上回る1,072件のセキュリティバグを修正した
  • 脆弱性検出システムは、複数のモデル、ChromeのCVE・Git履歴の知識ベース、SECURITY.md、別の批評エージェントを組み合わせ、インターネットとローカルシステムへのアクセスを厳しく制限した環境で動作する
  • 自動分類は、スパム・重複の除去、再現とスタックトレースの収集、深刻度などのメタデータ追加、担当者割り当てを行い、毎月数百時間分の開発者作業を削減すると推定される
  • 修正公開後に悪用されるまでのパッチギャップを縮めるため、週2回のセキュリティリリースを試験し、再起動なしで子プロセスを置き換える動的パッチとmacOSの自動再起動を開発している
  • 個別のバグ修正にとどまらず、MiraclePtr・std::span・Rustでメモリ安全性を高め、提出時点のAI検査と2,300件以上の外部依存関係の自動更新により脆弱性の流入を防ぐ

AIが変えたセキュリティバグのライフサイクル

  • LLMは、人間のセキュリティ専門知識だけで扱える規模を超えて自動脆弱性検出を拡張しており、Chromeは数百件のセキュリティバグをより速く発見・修正するためにAIを活用している
  • 一般的な機能バグがUIのフリーズのような問題を引き起こすのに対し、セキュリティバグは攻撃者が個人データを読み取ったり、ユーザーに気づかれずにコンピューターを制御したりするエクスプロイトに利用される可能性がある
  • セキュリティバグは、発見、分類、修正、修正版を含むChromeの配布、ブラウザーの再起動と適用という順序で処理され、すべての段階をできるだけ短縮することが目標である

脆弱性検出の拡大

  • Chromeセキュリティチームは、数年にわたりLLMベースの検出技術を発展させてきた
  • 2026年初頭に構築したGeminiエージェントハーネスは、より広いChromeコードベースで検出効率を高め、誤検出を減らした
    • 発見されたサンドボックス脱出バグは、侵害されたレンダラーがブラウザーをだましてローカルファイルを読み取らせることができるもので、コード内に13年以上残っていた
  • 検出ハーネスには次の機能が追加された
    • オープンウェイトモデルと独自モデルそれぞれの強みを利用するモデル相互運用性
    • 既存の全CVEとChromeの全Git履歴を含む知識ベース
    • 信頼境界と脅威モデルを明確に伝えるSECURITY.md作成ガイドライン
    • 別コンテキストでSECURITY.mdを読む批評エージェント
    • モデルの非決定性と時間に伴う改善を反映するためのコードベース反復検査
  • AIは一般のインターネットにアクセスできないロックダウンされた機器上で、保存されたソースコードのみを分析する
    • すべてのネットワークリクエストを傍受し、アプリケーションと宛先に基づく許可リストを適用する
    • モデルを無制限モードで実行せず、サブエージェントによるシステム変更と、指定されたソースディレクトリ外のファイルアクセスを制限する
  • AI検出は既存のセキュリティテストを置き換えるものではない
    • ファジングは、互いに離れたコード領域の長距離相互作用や、無関係に見える複数の操作の組み合わせから生じるバグに特に効果的である
  • 外部研究者はChrome Vulnerability Reward Programを通じて、難しく影響の大きい脆弱性を継続して見つけるよう報奨を受ける
    • 2026年初頭にはすべての種類の報告が増加し、3月には2025年全体を上回るバグ報告が寄せられた
    • これに伴いVRPを変更し、内部検出結果に追加価値を提供し、自動処理パイプラインが受け入れやすい報告に集中するようにした

自動分類とマルチエージェント修正

  • 以前はセキュリティ報告1件の分類に5分から30分以上かかり、主に人間の専門知識に依存していたが、現在はルールベースのシステムとAIを組み合わせて処理量と精度を高めている
  • 自動分類は4段階で進む
    1. スパムと重複を除去し、受付基準を満たしているか、Chromeのセキュリティ脆弱性について明確な説明があるかを検査する
    2. 概念実証と再現可能性を確認し、該当するOS・ブラウザーバージョンで試験したうえで、スタックトレースなどの情報を添付する
    3. バグが最初に入り込んだ時点と深刻度を追加する
      • 自動適用しやすいよう深刻度ガイドラインを明確に整備した
      • 開発者は誤った深刻度等級を変更し、SECURITY.mdでセキュリティ境界情報を補足できる
    4. 問題を正しいコンポーネントと担当者へ自動で割り当てる
  • 正確な測定は難しいが、自動分類により毎月数百時間分の開発者作業を削減していると推定される
  • 脆弱性修正にはマルチエージェントのワークフローを適用する
    • 修正エージェントが問題ごとのコンテキストを受け取り、複数の候補パッチを生成する
    • 批評エージェントが最も適した候補を評価し、開発者のレビューに必要な成果物を作る
    • 2つのエージェントがコードレビューに似た反復作業を行い、機能動作、Chromium・Googleスタイル、ローカルコード慣例への準拠を検査する
    • テスト作成エージェントが、開発者レビュー前にChrome対応プラットフォームと構成全体でテストを確認し、最大で数週間の時間を節約する
  • 現在、ほとんどの脆弱性についてLLMが修正候補を生成している
    • Chrome 149と150ではセキュリティバグ1,072件を修正し、直前の23マイルストーンの合計を上回った
  • DeepMind・Project Zeroと協力したBig SleepとCodeMenderはCIに統合され、すべてのCLを24時間ごとに検査する
    • 5月の1か月間で、重大なS1+問題を含む20件超の脆弱性が本番環境に到達する前にブロックされた

パッチギャップの短縮とアップデート適用

  • 修正コードが公開オープンソースリポジトリに入ってからユーザーへ配布されるまでの間に、攻撃者がそれをリバースエンジニアリングして悪用できるN-day攻撃の期間をパッチギャップという
  • メインツリーに反映された修正が、大多数のユーザーが利用するStableチャネルに届くまで通常は数週間かかる
    • 深刻度に応じて修正を現在のStableリリースブランチへ直接マージし、新たな衝突や回帰を継続して監視する
    • 主要なChromeマイルストーンを2週間周期へ移行したことで、毎週セキュリティアップデートを提供している
    • AIベースの攻撃速度に対応するため、週2回のセキュリティリリースも試験中である
  • Stableに到達したすべてのセキュリティバグは、内部・外部のどちらで発見されたかに関係なく公開文書化する
    • 手作業のボトルネックをなくし、発見から公開までの時間を短縮するため、パッチからリリースノートとCVE説明を自動生成する作業を進めている
  • Chromeは2008年から、新しいバイナリをバックグラウンドでダウンロードして準備し、次回再起動時に適用する自動更新を使っている
    • 分類・修正・テスト・配布には1〜2日かかるが、ユーザーが再起動するまでの待ち時間もN-day悪用リスクに大きく寄与し得る
    • 再起動は作業を妨げ、別途予定を組む必要があるため、ユーザーが先延ばししやすい
  • ユーザーに再起動の負担を押し付けないための機能を開発中である
    • 動的パッチはChromeのマルチプロセス構造を利用し、Renderer・GPUなどのバックグラウンド子プロセスを新しいバイナリへ順次置き換えるもので、ほとんどの場合にブラウザー全体の再起動をなくすことを目標とする
    • 複雑な状況でもセッションを復元できるよう、より多くの状態をローカルに保存する方法を検討している
    • 完全なセッション復元が保証される時点で自動的に再起動する
    • Chrome 150はmacOSで、すべてのウィンドウが閉じられているがアプリがバックグラウンドに残っている状態を検知し、保留中のアップデートがあれば自動再起動する
  • 長期的には、継続的な動的パッチと、妨げの少ないタイミングでの自動再起動を組み合わせた常に最新状態のブラウザーを目指す
  • 企業IT管理者向けの推奨事項は次のとおり
    • RelaunchNotificationポリシーを使い、通知から所定期間後の強制再起動まで段階的に適用する
    • 変更内容の検証が必要なセンシティブな環境ではChrome Extended Stable Channelを使う
    • Chrome Enterprise CoreまたはPremiumのOS非依存ダッシュボードでブラウザー全体のバージョンを追跡し、アップデートをきめ細かく管理する

C++防御とRustへの移行

  • Chromeは既存のC++脆弱性をランタイムで無力化すると同時に、長期的にはメモリ安全な言語へ移行する二重戦略を用いている
  • Chromiumコードの大半はC++であるため、ツールチェーンとランタイム緩和が即効性のある第一防衛線となる
    • 強化された標準テンプレートライブラリとMiraclePtr系の技術により、Use-After-Free（UAF）脆弱性を減らしてきた
  • C++防御ロードマップは3つの柱で構成される
    • MiraclePtr・MiracleObjectの拡大
      • MiraclePtrをSkia、ANGLE、Dawn、C++イテレーター、std::コンテナーへ拡大する
      • MiracleObjectは、局所的なランタイム性能を時間的安全性と引き換えにし、GPUメインスレッドのUAF脆弱性の最大90%を無力化することを目標とする
    • std::spanへの移行
      • ポインターとサイズを一緒に使う従来構造を、コンパイラーが検査するstd::spanへ置き換え、範囲外アクセス（OOB）を排除する
      • Chrome自身のコードの97%が厳格なunsafe-buffer警告とともに問題なくコンパイルされており、Skia・ANGLE・Dawnにも要件を拡大している
    • 構造・アロケーションの強化
      • メモリアロケーション計算にchecked mathを適用し、整数オーバーフロー経路を防ぐ
      • ポインターを含む型と非ポインター型を厳密に分離する追加ヒープパーティショニングにより、UAFの悪用を難しくする
  • C++ランタイム緩和は今後数年以内に限界効用が低下すると見ている
    • ランタイム検査はコンパイル時保証よりコストが大きく、強く緩和されたC++バイナリでもRule of Twoを守るには、性能を制限する厳格なサンドボックスが必要である
  • 長期的にはRustへの移行を推進する
    • Rustフライホイール: ChromiumベースのAPIとツールをRustに直接提供する中央SDKを構築し、新しいコンポーネントで日常的に選べるようにする
    • バグ密集領域の除去: 複雑なデータパーサー、画像コーデック、フォントスタックのように、過去にバグ密度が高かったコードを戦略的に置き換える
    • 高権限のモジュール化: 新しいモジュールをRustで書き、ブラウザープロセスのような高権限領域でも、サンドボックスの性能コストなしに複雑な機能を実行できるようにする
  • ブラウザー最上位UIをHTML・CSS・TypeScriptで実装し、既存のC++フレームワーク依存をさらに減らす案も検討している

コード提出前に脆弱性をブロック

  • コードベース全体を定期的にスキャンする方式だけではChromeの速い開発ペースに追いつくのが難しいため、AI検査をコード提出時点の近くに配置している
  • CIとコミットキュー（CQ）の防御モデルは変更差分を自動検査する
    • std::spanへの移行修正を提案する
    • ダングリングポインターを示す
    • 数値演算の安全性を強制する
  • 単独では安全なコードでも、別の場所の小さな論理変更と組み合わさると、深刻な潜在的セキュリティ問題になり得る
  • CQ内の継続的なLLM意味解析は、従来の静的解析が見逃す微妙または複雑な相互作用を見つけ、コードがツリーに入る前にブロックする

オープンソースエコシステムと外部依存関係

  • WebセキュリティはChrome自身だけでなく、オープンソースプロジェクトとメンテナーの対応能力にも依存する
    • Googleは、メンテナーが脆弱性報告に迅速に対応するためのツールと支援を確保できるよう、他の参加者とともにAlpha-Omegaプロジェクトに1,250万ドルを寄付した
    • Akritesプロジェクトの創設メンバーとして参加しており、中央脆弱性報告窓口とセキュリティインシデント対応チームを提供し、アップストリームメンテナーの負担を減らすことを目標としている
  • ChromiumとV8、BoringSSL、Skia、ANGLE、Dawnのような関連プロジェクトには2,300件を超える外部依存関係がある
    • このうち約1,700件が、Androidデバイス、エッジコンピューティングプラットフォーム、大規模クラウド企業スタックなど、さまざまな製品を通じてユーザーに配布されている
  • 自動脆弱性検査パイプラインは、Google内部フィードと米国政府のNVD、オープンソース中心のOSVデータを収集する
  • 事後モニタリングだけではリスクギャップが残る可能性があるため、すべてのChrome外部依存関係を最新のアップストリーム版へ先行更新する自動更新パイプラインへ移行し始めている
  • 自動化の過程ではGOSSIPのようなプロジェクトの安全シグナルを利用し、外部オープンソースエコシステムの他のリスクも反映する

継続的に保護されるブラウザー

  • LLMによって発見・修正されるバグ数が増えることは失敗ではなく、修正されたバグ1件ごとに攻撃者が利用できる足場が1つずつ減る
  • 発見と修正だけでは十分ではなく、攻撃者が悪用する前に修正版を配布し、ユーザー環境へ適用しなければならない
  • より速いリリース、動的パッチ、妨げの少ないタイミングでの自動再起動、構造的防御を組み合わせ、ユーザーを妨げることなく継続的に保護されるChromeを目指す

関連記事

1件のコメント

 
GN⁺ 2 시간 전
Hacker Newsの意見

  • 最近仕事が忙しい間に パフォーマンス最適化 でAIをかなり使ってみたが、上位レベルの方向性を定めるのにはほとんど役に立たなかった。SQLクエリの怪しい箇所を指摘しても前後の性能差はほぼなく、無駄な提案に時間を取られ、他の人が未加工のAI出力を意味のある貢献のように投げてくることにまで対処しなければならなかった
    ただし、自分で見つけた変更を実装したり、JOINをCTEに移す作業はずっと楽になった

    • 役に立たない長文の提案 は本当にうんざりする。同僚の一人はSlack、Jira、コードレビュー、メールを含むすべての非同期コミュニケーションでClaudeを使っていて、簡単な質問にも範囲がどんどん膨らむ巨大な文章の壁で返してくる
      AIツールに「簡潔に」「質問にだけ答えて」「求めていない情報は出さないで」と繰り返しても必要以上に出力してきて、トークンをもっと消費させようとする微妙な試みに見える
    • AIに自分の仮説を検証する 必要なツールをすべて与え、ライフサイクル全体を繰り返し実行させると、驚くほどうまく機能する
    • クエリと一緒に EXPLAIN ANALYZE の出力 を渡せば、AIは最適化にそれほど苦労しないので、クエリ最適化には役に立たなかったという評価は意外だ
    • どの モデルを使ったのか も明らかにすべきだ。最先端モデル同士でも差は非常に大きく、ベンチマーク上の差以上に、実際にはOpus 5.0はCursor Grok 4.5とはまったく別格で、SonnetやComposerとも比較しにくい
    • コードだけを見せて パフォーマンス最適化 を探させたのが間違いだった。性能プロファイル、クエリプラン、テレメトリ資料を提供し、変更前後を測定すべきだ
      コードテキストだけではキャッシュサイズ、データベース容量、ネットワーク遅延は分からないのだから、こうした文脈を与えたほうがより良い結果を得られる

  • 先月5月のベルリン Pwn2Own でFirefoxが賞金をまったく支払わなかったという事実が重要な資料だ。2007年以降のすべてのイベントで賞金を支払ってきたのに、確認された脆弱性が一つもなかったというのは、簡単に見つかる脆弱性がほぼなくなり、この種のモデルがある程度有用だというシグナルに見える

  • 多くのバグを修正できるという点は信じるが、実際のプロセスが気になる。Googleがブログを出し、管理職が上層部に AI導入の成果 を示せるよう、数回のスプリントにわたってバグ修正を促し、チームが普段よりはるかに多く働いた可能性もある

    • Googleは何十年も あらゆるものを自動化 してきており、ファザーやProject Zeroもその流れに属する。その上にLLMを加え、ハーネスと開発ツールを改善して、検出・分類・修正・確認をエンドツーエンドでつなぐのは自然な次の段階だ
      LLMの性能は実行される反復構造に左右され、その構造はバリデータの品質に左右されるのだから、管理職の実績アピールがなくても十分説明できる
    • 静的解析や ファジング のような新しい分析ツールを導入するたびに、新たに見つかるバグが最初は急増し、それを処理した後は発見頻度がまた下がった可能性が高い
    • 2026年初頭にすべてのカテゴリのバグ報告が増え、3月には2025年通年より多くなっていたなら、AIの利用で バグ総数そのもの も大きく増えたのかもしれない。たとえば2025年には50件見つけて45件直したが、2026年には500件見つけて450件直した、という図かもしれない
    • AIがコードを素早く解釈して バグのバックログ をより速く処理し、コードレビューやセキュリティレビューも速くなって、さらに多くの問題を見つけられるようになる可能性がある。Linuxカーネルをはじめ、WindowsやAppleでも似た現象が起きているようだ
    • Chromeエンジニアリング組織には、この10年あまり、Google上層部が事業価値を認めない限りバグを修正しない 無気力な文化 があったのかもしれない。今はAIをもっと売るためにバグを修正し、その功績をAIに帰するという事業上の動機が生まれたのではないかと疑っている

  • AIは野放しに働かせるのではなく 加速ツール として活用すべきで、批判者はそこを混同しているように見える。投資収益が悪いからといってExcelに腹を立てるようなストローマン論法に近く、これ以上論争するより、きちんと効率よく使おうとしている人たちと静かに使い方を共有したい

    • そもそもAIを どう使うべきか が明確ではない。片方はあらゆる文脈を与えて好きに実行させろと言い、もう片方は細かく導きつつすべての結果をレビューしろと言い、その両方に支持がある
      放置すると数回の反復で結果は悪化し、丁寧に導けば価値は出るが、その手間は、特に反復作業がある場合、結局自分でコードを書くのと大差ない
    • 実際にはAIは開発者を加速するためのツールだが、経営陣と最先端研究所 は、もうすぐコードを読む必要すらなくなり、プログラマーも消えるかのように宣伝している
    • AIが今や 国際安全保障と政治 の問題になっている以上、この分野にはプロパガンダが多い可能性があり、現在の論争は10年前の政治論争と似た形をしている
    • Bitcoinが自分の問題をどう解決したかを説明しても、みんな不可能だと言っていた議論を思い出す。だからといってAIがBitcoinと同じだと言いたいわけではない
    • バグ修正、コード改善、リファクタリング はAIに最も向いている作業だ。古いソフトウェアをようやく磨けるのではと期待していたが、新機能開発の高速化ばかり求められてきた人たちは、置かれた環境次第で歓声を上げたり冷笑したりすることになる

  • 自動修正のうちいくつが 差し戻されたのか、新しいバグをいくつ作ったのか、検出エージェントの偽陽性率がどれくらいなのかは分からない。投稿には成功した数値しかなく、うまくいかない可能性についてはまったく触れられていない

    • 実際には AI のおかげでバグを多く見つけて修正したと宣伝しているが、AI でできるだけ多くのバグを修正することが重要業績評価指標になっており、古くて簡単なバックログ項目を AI で見つけて人間が直した可能性が高い
    • M146 以降の バグ発見数の急増がより良いテストによるものなのか、そもそも新しいバグがより多く入り込んだからなのかを説明していない
    • Amazon には AI の成功事例を共有する場は多いが、失敗や失望を共有する場はない。経営陣が一方的な話だけを聞き、AI について誤った判断を下すのも当然だ
    • そのバグのうち AI が新たに作ったものがいくつあるのかも気になる
    • ブラウザセキュリティでは、新しいバグが少し生じることは大きな問題ではないかもしれない。2012 年の Pinkie Pie 攻撃も 6 個のバグをつなげる必要があり、その後には 10 個以上をつなげる攻撃も登場しているため、そのうち 1 つだけ修正しても攻撃全体は無力化される
      バグを 10 個修正しながら 2 個新たに作ったとしても、単独で悪用可能な深刻なバグでない限り純利益は大きい。ブラウザ攻撃はますます長い 脆弱性チェーンを必要とするため、AI で潜在的なバグを見つける利点は無視しがたい
      https://blog.chromium.org/2012/05/tale-of-two-pwnies-part-1....

  • 今後 Google が Chromium には公開の 集団的バグ探索は不要だと判断し、公開開発をやめるのではないかと懸念している。そうなれば現在の Chromium 系は最後の公開版の事実上のフォークとなり、Gemini の支援を受ける Chrome ほど保守する資源がないため、各フォークの管理難易度に差が出るかもしれない

    • Google はすでに Chrome と Chromium の方向性を強く統制しているので、オープンウェブを重視するなら Firefox を使うべきだ

  • AI 批判はしばしば、コードを盲目的に生成するのが悪いという狭い範囲に集中しており、その点は簡単に認められる。しかし、敵対的テスト、開発者の仮定の検証、リファクタリング提案、小さな開発ツール、ガイド付きコーディング、大規模コードベースの依存関係や動作の追跡はその反対側にあり、大きな助けになりうる
    盲目的なコード生成に当てはまる批判を、こうした活用全体とあまりに安易に混同している

    • AI は特定のやり方で使うべき ツールだ。望む方向を指定する必要があり、すべての問題を魔法のように解決してくれると期待してはいけない
    • AI には個人がすべて持てるわけではない能力があるが、ユーザーより賢いわけではなく、ユーザーが修正しなければ誤った判断をしばしば下す

  • そもそもこのバグのうちいくつが LLM が書いたコードから生じたのかが核心だ。バグを 100 倍多く作り、100 倍多く直すことは自慢にならない

    • Chrome は 20 年以上続くプロジェクトで、LLM は最近登場したものであり、LLM コード生成器が出てきたからといってコードレビューやテストを緩めてもいない。13 年前の issue にも言及されているだけに、影響を受けた領域で最近の開発が多くなかった可能性が高い
      オープンソースプロジェクトなので、実際に LLM が作ったバグなのか自分で確認することもできる
    • コーディングを AI にますます委ねていくと、人間の 潜在的なバグを識別する能力も低下する可能性がある。AI が書いた機能をコミット前にまた AI で検査していると、基盤インフラを動かすコードでさえ人間には理解できない世界に近づいていく
    • Git の統計を見ると、提出された コード行数は劇的には変わっていない。誰もが低品質な AI コードをそのままマージしているわけではなく、既存の主要組織は無責任な vibe coding の成果物をたいていマージしていない
    • AI がより少ないバグでコードを作れると仮定するなら、新しいバグが 100 倍増えたというのは 新機能開発速度が 100 倍以上速くなったことを意味する。モデルが 13 年前の致命的バグを見つけられるなら、同じ能力でそうしたバグのない新しいコードも書けるはずだ
    • プロジェクトの歴史や規模を無視し、根拠なく バグが 100 倍増えたという数字を作り出してそれを核心問題だと呼ぶのは不合理だ。AI の話題では、現実を無理やり構成しようとする態度がとりわけ多く見られる

  • Chrome がどこで何をしていてもユーザーを追跡しようとする 行動追跡バグも修正したのか気になる