Googleは2026年10月1日、オープンソースソフトウェア脆弱性報奨プログラム(OSS VRP)への製品脆弱性の新規報告受付を停止した。 現在のプログラム規則 には締切が明記されている。サプライチェーン関連の報告は引き続き受け付ける。またGoogleは、10月1日より前に提出された製品報告には影響しないとしている。Google Cloudが保守する一部のリポジトリで、脆弱性がCloud製品に影響する場合は、 Cloud VRP が製品報告を受け付ける可能性がある。

今回の停止に先立ち、Googleは 3月19日に規則を更新した。当時、GoogleはAI生成報告が増え、誤ったトリガーやセキュリティ上の影響がほとんどない内容が含まれていると説明していた。 10月1日の声明では、 自動化された 報告が増え、その大多数が無効だったと述べた。ただし、10月の声明は自動化された報告すべてをAI生成と位置づけてはいない。Googleは2027年第1四半期に更新すると約束したが、再開日は示していない。

大きな変化

OSS VRPはこれまで、対象プロジェクトの階層や証拠要件に応じて、Googleの対象オープンソース製品の脆弱性報告を受け付けていた。10月1日以降、新たな製品報告の窓口は停止している。ソースコードや配布ビルドを侵害し得る発見については、サプライチェーン窓口が引き続き受け付ける。提出済みの製品報告も処理が続く。研究者は報告フォームを選ぶ前に、発見の種類と製品への影響を見極める必要がある。他のプログラムが利用できるかどうかは、リポジトリがGoogle所有かだけでなく、Googleの規則で判断される。

報告前に窓口を見極める

まず OSS VRPの規則 と、影響を受けるリポジトリの識別情報・現行バージョンを確認する。Googleによると、対象にはGoogle所有のGitHub組織の公開リポジトリにあるソフトウェアの最新バージョンと、他プラットフォームの一部リポジトリが含まれる。ただし、この範囲にある問題すべてが報奨対象になるわけではない。

発見内容

Googleの規則で現在利用できる窓口

Google OSSの新たな製品脆弱性(下流製品で使われるソフトウェアの欠陥など)

停止中は、新たなOSS VRP製品報告として提出しないこと。実証した影響が他プログラムの規則を満たすか確認する。

Google OSSのソースコード完全性や配布ビルド成果物を損ない得る弱点

OSS VRPのサプライチェーン基準を確認し、Googleの 脆弱性報告フォーム でOSS VRPを選び、リポジトリURLを記入する。この窓口は継続している。

10月1日より前に提出済みの製品脆弱性

既存の報告を引き続き処理する。Googleによると、停止は未解決の報告に影響しない。

Google Cloudが保守するリポジトリの問題で、Cloud製品・サービスに影響するもの

該当製品の階層も含め、 Cloud VRPの規則を確認する。Googleは、この種の報告の一部を同制度で受け付ける可能性があるとしている。リポジトリの場所だけでは不十分だ。

LLMなどの生成AIシステムとのやり取りが問題の本質となる、GoogleまたはAlphabetのAI製品の問題

該当する AI VRPの規則を確認する。AIを使って一般的なコードの欠陥を見つけただけでは、その欠陥がAI VRPの対象になるわけではない。

提案するセキュリティ改善やパッチ

対象プロジェクトや変更について、別制度の Patch Rewards Programの規則 を確認する。これはパッチ報奨制度であり、停止中の同じ脆弱性報告を提出する代替窓口ではない。

Googleの OSS規則 には、製品脆弱性を受け付けていた以前の基準も残っている。たとえば、一部のメモリ破損はOSS-Fuzzで再現するか、パッチがマージされている必要がある。これらの記述はその報告種別の要件だが、10月の新しい締切より下にある。停止中に新たなOSS VRP製品報告を提出する手段にはならない。

継続中のOSS報告に必要なもの

サプライチェーンの発見では、Google OSSのソースコード、ビルド成果物、配布パッケージを変更できる悪用可能な経路を示すよう、規則は求めている。メンテナーが外部プルリクエストを承認した後にしか成立しない状況は、内部者リスクとして扱われ、サプライチェーン脆弱性の報奨ではなくクレジットの対象となる場合がある。対象面として、リポジトリとビルド設定、リリース基盤、配布認証情報などが挙げられている。これは範囲の説明であり、他者のインフラを試験する許可ではない。

このガイドは2026年10月5日に確認したGoogleのプログラム文書に基づく。BIG CHANGEは脆弱性の検証も報告の提出も行っていない。提出前にGoogleの 報告手順が求める項目をそろえる。

  1. リポジトリURL、影響を受けるソフトウェアのバージョン、発見が当てはまる最近のビルドまたは設定。
  2. 欠陥、発生条件、セキュリティ上の影響を簡潔に説明する。コード警告だけで悪用可能な脆弱性が証明されたと決めつけず、攻撃シナリオを示す。
  3. 再現手順と、可能であればビルド可能な概念実証。関連する出力やクラッシュダンプがあれば添付する。観測した結果と推定する影響を分けて記述する。
  4. 適切なプログラムと報告先。OSSサプライチェーン報告では、脆弱性フォームのBug LocationでOSS VRPを選択し、リポジトリURLを指定する。CloudやAIでは各プログラムの適用範囲とフォームの指示に従う。

Googleは可能な限りローカルで試験し、他の利用者への妨害を避け、大量の通信を発生させる自動テストを行わないよう求めている。 Cloudの規則 は顧客所有のリソースを試験することを禁じている。 AIの規則 は、報告者が問題を検証し、対象範囲内の脅威を平易な言葉で説明するよう求める。こうした境界は報告の質と同じくらい重要だ。

各プログラムのページは公開されており、脆弱性報告の提出に料金はかからないと説明している。実際に必要なのは、具体的な発見、対象となるターゲット、選んだプログラムの規則に沿った報告だ。報奨は裁量で決まり、プログラム、プロジェクト階層、影響によって異なる。現行OSS報奨表には新たな製品脆弱性の報奨はなく、対象階層のサプライチェーン報奨額は引き続き掲載されている。提出したことや報告を整えたことだけで支払いが保証されるわけではない。

Googleが受付を変更した理由

Googleは3月の投稿で、研究者がAIの出力を検証すればAI支援研究は有用だと説明した。一部報告はトリガーを捏造したり、到達可能で重大なセキュリティ影響を示さずにコーディング上の誤りを指摘したりしていたという。4月の更新では、下位のOT2・OT3プロジェクトで製品脆弱性などのセキュリティ問題に対する報奨やクレジットを廃止した。10月の停止は、プロジェクト階層を問わず 新しい OSS VRP製品報告に対象を広げた。 TechCrunch も停止を報じた。Googleの公開発表は規則変更と説明された理由を示すが、提出件数や、無効報告のうちAIを使った割合を独立に測定した情報はない。

研究者が直ちにすべきことは、現行規則に照らして発見を分類し、実際のセキュリティ上の影響を示し、現在利用できる窓口だけを使うことだ。Googleは2027年第1四半期に製品報告の経路を更新するとしている。それまでは、10月の締切が新たなOSS VRP製品報告に適用される。

出典と参考資料