Google、オープンソースの報奨金プログラムで製品脆弱性の受付を停止 - 10月1日から、更新は2027年第1四半期に

GoogleがOSS VRPの規約を改め、2026年10月1日以降は製品脆弱性の報告を受け付けないと明記した。サプライチェーン侵害の報奨金は表に残っており、停止したのは製品脆弱性の区分だけ。理由として自動化された投稿の増加を挙げたと報じられている。

Google security open-source bug-bounty vulnerability AI-agents

Googleのオープンソース向け脆弱性報奨金プログラム（OSS VRP）の規約に、2026年10月1日以降は製品脆弱性の報告を受け付けないという記述が入った¹。この区分について同社は、作り直しの作業を続け、2027年第1四半期に更新を示すとしている。

停止したのは製品脆弱性という区分で、プログラムそのものではない。規約の報奨金表では、サプライチェーン侵害の金額（最上位ティアで3,133.7〜31,337ドル）と「その他のセキュリティ問題」の金額は残り、製品脆弱性の行は4つのティアすべてがハイフンになっている¹。

何が止まり、何が残ったか

OSS VRPは、Googleが公開しているオープンソースプロジェクトの脆弱性に報奨金を出すプログラムで、同社はGolang、Angular、Fuchsiaといったプロジェクトの保守者として位置づけを説明している²。報告の区分は大きく3つあり、停止したのはそのうち1つである。

区分	OT0（Flagship）	OT1（Important）	OT2（Standard）	OT3（Low-priority）
サプライチェーン侵害	$3,133.7 - $31,337	$1,337 - $13,337	$500 - $3,133.7	-
製品脆弱性	-	-	-	-
その他のセキュリティ問題	$1,000	$500	-	-

規約はサプライチェーン侵害について、ソースやビルドの完全性に影響する報告を何よりも歓迎すると書いている¹。例として挙がっているのは、リポジトリのmainブランチにコードを入れられること、Google OSSのGitHub Actionsの設定の不備、配布物に署名する鍵の侵害などで、ビルド基盤側から配布物の改ざんに到達する経路は引き続き対象になる。

振り替え先も規約に書かれている。Google Cloudの製品に影響する一部のリポジトリについては、Cloud VRP経由で製品脆弱性の報告を受け付ける可能性があるとしている。それ以外については、他のVRPプログラムで影響を探してそちらへ出すか、Patch Rewards Programを使うことを勧めている¹。10月1日より前に提出された製品脆弱性には、今回の変更は影響しないとも明記されている。

理由として挙がっているもの

規約ページ自体には、停止の理由が書かれていない。TechCrunchは、GoogleがXへの投稿とプログラムのサイトで、自動化された投稿が大きく増え、その大半が有効でないことが停止の理由だと説明したと報じている³。同誌は、AIが生成した中身のない報告（AIスロップ）が報奨金プログラムにとって深刻なリスクになるという専門家の警告を昨年報じていたとも書いている。

ここで区別しておくと、報道が引用しているGoogleの説明は自動化された投稿についてのものであり、「AI」はTechCrunchの見出しと解説の側の語である。自動化された投稿がどれだけあったのか、どのプロジェクトで問題が大きかったのかという数値は、規約にも報道にも出ていない。

ハルシネーションを含む報告は、受け取った側が中身を読んで初めて無効だと分かる。判定の工数が投稿の量に比例して増えるため、受付を続けるか止めるかという運営判断に直結したと考えられる。

受付基準は細かく絞られている

規約には、製品脆弱性の受付条件がティアごとに書かれている。OT0・OT1ティアのリポジトリでのメモリ破壊の脆弱性には、OSS-Fuzzでの正確な再現手順か、対象リポジトリにマージ済みのパッチのどちらかが要件とされている。同じ規約は、これらのティアでもメモリ破壊以外の脆弱性にはマージ済みパッチを求めないとしている。OT2（Standard）とOT3（Low-priority）ティアについては、製品脆弱性を金銭的な報奨の対象外としている¹。

同じ規約には方針も明示されている。重要なプロジェクト（OT0・OT1）は関連する場合にOSS-Fuzzと統合することを目指しており、個々のメモリ破壊の問題をトリアージするよりそのほうが堅牢で規模に耐えるからだ、という説明である¹。個別の報告を人手で捌くより継続的なファジングに寄せるという向きは、今回の受付停止と同じ方向を指していると考えられる。

規約には、これは競技ではなく実験的かつ裁量的な報奨プログラムであり、いつでも中止しうるという条項もある¹。

報告する側がいま確かめるべきこと

Googleのオープンソースプロジェクトに製品脆弱性を見つけた場合、報奨金の経路は10月1日以降なくなっている。実務上は、その脆弱性がサプライチェーン侵害として成立するか（ソースやビルドの完全性に届くか）、Google Cloudの製品に影響するリポジトリかを先に判定し、該当すれば区分や提出先を変えて出すことになる。どちらでもなければ、報告ではなくパッチの提出に対して支払うPatch Rewards Programに切り替わる。同プログラムの規約は、条件を満たす提出への報奨を100ドルから15,000ドルの範囲としている⁴。

ここで注意が要るのは、Googleの案内が1か所に揃っていない点である。プログラムの概要ページには、2026年10月5日時点でも製品脆弱性の報奨金レンジ（Flagshipで500〜7,500ドル、Standardで101〜3,133.7ドル）が掲載され続けている²。規約ページの表ではこの区分がハイフンになっているが、どちらが最新かはどちらのページにも書かれていない。報告の前に規約ページ側を確認するのが安全である。

見つける側と受け取る側の非対称

自サイトで追ってきた範囲では、ここ数か月の話題は「AIが脆弱性を見つける側」に集まっていた。Wizは、AIのレビューが通したPRの穴をAIが5日で見つけて突いた事例をSnowflakeの調査結果として公開し、Hacktronはlibheifの脆弱性を起点にOpenAIの社内リポジトリに到達した攻撃を公表した。Cursorは9月に、PRごとに悪用可能なバグを報告するSecurity Reviewボットを出している。

今回止まったのは、その反対側——報告を受け取って判定する経路である。見つける側の生産量が機械で上がっても、受け取る側の判定は人手に残る。この非対称は、報奨金プログラムに限らず、OSSのイシュートラッカーやレビュー待ちのキューでも同じ形で現れうると考えられる。自社のプロジェクトで外部からの報告や貢献を受け付けている場合、受付の要件を再現手順やマージ済みパッチの有無で絞る設計は、GoogleがOT0・OT1のメモリ破壊の脆弱性に課している要件と同じ発想になる。

Googleが2027年第1四半期に示すとしている更新の中身はまだ分からない。再開の条件として受付基準の変更が入るのか、区分そのものが作り替えられるのかも書かれていない。