Google、OSS脆弱性報奨金で「製品脆弱性」の新規受付を一時停止―自動化報告の大半が無効、AI生成レポート急増が背景

Googleは2026年10月1日、Open Source Software Vulnerability Reward Program（OSS VRP）で、オープンソースソフトウェアの「製品脆弱性」に関する新規報告の受付を一時停止しました。

Google Bug Huntersは、理由について「自動化された報告が大幅に増加し、その大半が有効ではない」と説明しています。一方、ソースコードやビルド環境の侵害につながるサプライチェーン関連の報告は引き続き受け付けており、10月1日以前に提出済みの製品脆弱性報告にも影響しません。

今回の措置は突然始まったものではありません。Googleは2026年3月時点で、OSS VRPにAI生成の低品質・無効な報告が急増していると公表し、再現性や実際のセキュリティ影響を確認できる証拠を重視する方向へルールを変更していました。

それでも自動化報告の増加が続き、最終的に製品脆弱性の新規受付自体を停止する形となりました。GoogleはOSS VRPの仕組みを再構成し、2027年第1四半期に更新情報を示すとしています。

Google OSS VRP一時停止のサマリー

• Googleが2026年10月1日からOSS VRPの「製品脆弱性」の新規受付を一時停止
• 理由は自動化された報告の大幅な増加
• Googleによると、自動化報告の大半は有効ではなかった
• サプライチェーン侵害に関する報告は引き続き受付
• 10月1日以前に提出済みの製品脆弱性報告は影響を受けない
• 一部のGoogle Cloud関連OSSはCloud VRPで製品脆弱性を受け付ける場合がある
• Googleは他のVRPやPatch Rewards Programの利用を案内
• 2027年第1四半期にOSS VRPの今後について更新予定
• Googleは2026年3月にもAI生成報告の「massive surge」を公表していた
• 3月のルール変更では、重要プロジェクトのメモリ破壊系脆弱性にOSS-Fuzzでの再現やマージ済みパッチを要求
• OT2・OT3の低優先度プロジェクトでは製品脆弱性や一部セキュリティ問題への報奨・クレジットを停止
• Chrome・AndroidのVRPでも2026年4月にAI時代を前提とした報奨制度の見直しが行われている

Googleは「OSSのバグ報奨金制度すべて」を停止したわけではない

今回の変更で注意したいのは、GoogleがOSS VRP全体を終了したわけではない点です。

停止されたのは、Googleのオープンソースプロジェクトに存在する「製品脆弱性」の新規報告です。

Google OSS VRPでは、脆弱性を大きく、

• Supply Chain Compromises
• Product Vulnerabilities
• Other Security Issues

などに分類しています。

今回停止されたProduct Vulnerabilitiesには、例えば、

• メモリ破壊
• パストラバーサル
• HTMLサニタイザーの不備
• セキュリティ上危険なデフォルト設定

など、OSS製品そのものの設計・実装上の問題が含まれます。

一方、ソースコードやビルド成果物の改ざんにつながるサプライチェーン侵害については、引き続きOSS VRPの対象です。

Googleは、GitHubトークンやパッケージマネージャーの認証情報を悪用して、Google名義のソフトウェアへバックドアを混入できるような問題を特に高い優先度で扱っています。

10月1日の措置以前から、GoogleはAI生成レポート急増を問題視

GoogleがAIを使った脆弱性報告の問題を明確に公表したのは、今回が初めてではありません。

2026年3月19日、Google Bug HuntersはOSS VRPのルール変更について発表し、「過去数週間にAI生成レポートが大量に増加した」と説明しました。

Googleが挙げた問題は大きく2つあります。

1つ目は、AIが「どのように脆弱性を発火させるか」について誤った情報やハルシネーションを含む報告を生成するケースです。

2つ目は、コード上のバッファオーバーフローなどを指摘していても、実際には到達不能なコードパスだったり、プロジェクトのセキュリティモデル上ほとんど影響がなかったりするケースです。

つまり、コード上の「怪しい箇所」を見つける能力と、

「実際に攻撃可能な脆弱性であることを証明する能力」

の間に大きな差が生じていました。

3月にはOSS-Fuzzでの再現やマージ済みパッチを要求

Googleは3月の時点で、単にAI生成報告を拒否するのではなく、「実際に再現できるか」を受付条件へ組み込む方向へ制度を変更しています。

Google OSS VRPではオープンソースプロジェクトを重要度別に、

• OT0：Flagship
• OT1：Important
• OT2：Standard
• OT3：Low-Priority

へ分類しています。

OT0にはBazel、Angular、Goなど、広く利用される主要OSSが含まれます。

OT0・OT1のメモリ破壊系脆弱性については、

• 既存のOSS-Fuzzターゲットを利用した正確な再現手順
• 対象リポジトリへすでにマージされた修正パッチ

のいずれかを要求するルールへ変更しました。

「脆弱性らしきコードを見つけた」という段階ではなく、再現性または実際の修正まで確認できた報告へトリアージ資源を集中させる狙いです。

OT2・OT3では製品脆弱性の報奨自体を停止していた

Googleは2026年4月にもOSS VRPのルールを追加変更しています。

OT2とOT3のプロジェクトについては、

• Product Vulnerabilities
• Other Security Issues

への金銭的報奨とクレジット付与を停止しました。

さらにOT2のSupply Chain Compromisesについても、最大報奨額を3,133.70ドルへ引き下げています。

つまりGoogleは2026年前半から、

「すべてのコード上の問題を同じ優先順位で人間が確認する」

運用から、

「重要プロジェクト、実際に悪用可能な問題、サプライチェーン侵害へ資源を集中する」

運用へ移行していました。

10月の一時停止は、このフィルタリングをさらに一段進めた対応とみることができます。

「AI利用禁止」ではない、問題は検証されていない大量報告

今回のGoogleの発表を「AIで脆弱性を探してはいけなくなった」と解釈するのは正確ではありません。

Googleは3月の発表でも、AIは大量の潜在的な脆弱性を発見するための強力なセキュリティ研究ツールになり得ると評価しています。

問題視しているのは、

• AIが生成した結果を検証しない
• 実際に再現できない
• 攻撃経路が成立しない
• セキュリティ影響がほぼない
• 同種の報告を大量送信する

といった使い方です。

10月1日のGoogleの表現も「AI-generated submissions」ではなく「automated submissions」です。

ただし、Googleは3月にAI生成報告の急増を明示しており、今回の問題は2026年を通じて続いていた自動化・AI利用による報告品質問題の延長線上にあります。

ChromeとAndroidでも「AIで見つけやすい脆弱性」から報奨の軸を変更

GoogleはOSS VRPだけでなく、ChromeやAndroidの脆弱性報奨制度についても2026年4月に見直しました。

Googleは、AIと自動化によって、

• テストケースから原因を説明する
• 修正案を作成する
• 既知問題の類似バグを探索する

といった作業が以前より容易になったと説明しています。

Chrome VRPでは、長文の説明よりも、

• 実際にバグが存在することを示す再現コード
• 必要な証拠

を簡潔に提出する報告を重視する方向へ変更しました。

Androidでも、AIツールでは見つけにくい脆弱性へ報奨を集中させ、Linuxカーネルの問題についてはAndroidやGoogleデバイス上で実際に悪用できる証拠をより強く求めています。

AIによって「候補を見つけるコスト」が急低下したことで、バグバウンティ側の評価軸が「発見」から「実証」へ移っています。

バグバウンティのボトルネックが「発見」から「トリアージ」へ移動

従来の脆弱性報奨制度では、

「人間が見つけられる脆弱性の数」

が大きな制約でした。

生成AIやコード解析エージェントが普及すると、この構図が変わります。

自動化ツールは短時間で、

• 危険に見えるコード
• メモリ安全性の問題
• 入力検証不足
• 権限処理の不備
• 既知脆弱性と類似するパターン

を大量に抽出できます。

しかし候補数が増えても、それらがすべて実際の脆弱性とは限りません。

結果として、ボトルネックは「脆弱性を見つける人」から、

「その報告が本当に攻撃可能かを確認する人」

へ移ります。

Googleの今回の措置は、AIによって脆弱性発見能力が高まった一方、人間によるトリアージ能力が同じ速度では増えないという構造的な問題を示しています。

企業の脆弱性管理でも「検出件数」だけをKPIにすると同じ問題が起きる

この問題はバグバウンティ運営者だけに関係するものではありません。

企業内でもAI搭載のSAST、DAST、SCA、コードレビュー、ASMなどが普及すると、検出される脆弱性候補は増加します。

しかし、検出件数を増やすだけでは、

• 実際に外部から到達可能か
• 認証が必要か
• 悪用コードが存在するか
• 重要資産へつながるか
• 事業影響があるか

といった優先順位が分かりません。

多数の脆弱性を同じ扱いにすると、修正担当者が低リスクのアラート処理に追われ、本当に危険な脆弱性への対応が遅れる可能性があります。

脆弱性管理の考え方と対応優先順位でも、CVSSだけでなく、実悪用状況、外部公開状況、資産重要度などを組み合わせて対応順を決める考え方を整理しています。

AI脆弱性診断では「再現性」「到達可能性」「影響」をセットで評価

AIを使った脆弱性探索を企業で導入する場合、単純な「検出数」ではなく、少なくとも次の情報をセットで扱う必要があります。

• 対象製品・バージョン
• 問題となるコード位置
• 攻撃成立の前提条件
• 到達可能なコードパスか
• 再現手順
• PoCの有無
• 想定されるセキュリティ影響
• 修正案
• 修正後の再テスト結果

GoogleがOSS VRPで重視する方向も同じです。

同社は現在のOSS VRPルールで、高品質な報告として、

• ビルド可能なPoC
• 最近のビルドを対象とした再現
• クラッシュダンプ
• 再現手順
• 影響するバージョン
• 攻撃シナリオ

などを求めています。

AIが出した検出結果をそのまま開発部門へ流すのではなく、人間または自動検証環境で実証してからチケット化する運用が必要になります。

脆弱性診断ツールの種類と選び方でも、検出方式だけでなく、誤検知の確認や運用負荷を含めて選定する必要があります。

サプライチェーン脆弱性は引き続き高額報奨の対象

Googleが製品脆弱性の受付を止める一方、サプライチェーン侵害の報告を継続している点も重要です。

現在のGoogle OSS VRPでは、Supply Chain Compromisesの報奨額は、

• OT0：3,133.70～31,337ドル
• OT1：1,337～13,337ドル
• OT2：500～3,133.70ドル

となっています。

Googleが例示するのは、

• GitHubトークンを漏洩させてmainブランチへ書き込める
• npmやPyPIの公開用認証情報を取得できる
• Google名義のパッケージへ悪意あるコードを混入できる

といった問題です。

単一アプリケーションの脆弱性より、ソフトウェア配布経路そのものを侵害して多数の利用者へ影響できる問題を高く評価する構造です。

OSS依存関係やソフトウェア構成を把握する方法としては、SBOMの意味・目的・必要性でも整理しています。

Googleは2027年第1四半期にOSS VRPの再設計方針を公表予定

Googleは今回の停止を「temporary」としており、OSS VRPの製品脆弱性報告を永久に終了すると発表したわけではありません。

同社は、自動化報告の増加に対応するため、この部分のOSS VRPを再構成し、2027年第1四半期に更新情報を示すとしています。

今後の焦点は、

• AI・自動化された報告をどのように事前検証するか
• PoCや再現環境をどこまで必須化するか
• 低優先度プロジェクトをどこまで人間がトリアージするか
• パッチ提出型の報奨制度へどこまで移行するか

です。

AIによって脆弱性候補を大量に生成できるようになったことで、バグバウンティは「誰が最初に問題らしきものを見つけたか」だけではなく、「誰が現実的な攻撃可能性と修正方法まで証明できたか」を評価する制度へ変化しつつあります。

出典

• • Google Open Source Software Vulnerability Reward Program Rules – Google Bug Hunters
  • Streamlining Google’s OSS VRP: Key Rule Updates – Google Bug Hunters
  • Open Source Security VRP – Google Bug Hunters
  • Evolving the Android & Chrome VRPs for the AI Era – Google Bug Hunters
  • Google Bug Hunters Key Stats – Google Bug Hunters