Google、AIによる報告が急増し、OSSのバグ報奨金プログラムを一時停止

Googleは2026年10月1日から、オープンソースソフトウェアの脆弱性に報奨金を支払う「OSS VRP」で、製品脆弱性に関する新規報告の受付を停止した。サプライチェーンに関する報告と、9月30日までに提出された製品脆弱性の報告は今回の停止対象には含まれない。同社は春にも、AI生成による報告の急増を受け、対象範囲を絞るとともに、再現手順などの証拠をより厳しく求めるよう制度を変更していた。今回の措置は、品質要件を強化して報告を選別する段階から、製品脆弱性の新規受付そのものを止めて制度を見直す段階へ移ったことを意味する。脆弱性の発見を加速できるAIを、検証や修正を担う人間の作業にどう結びつけるかが、今後の制度設計で問われる。

製品脆弱性の受付は停止、サプライチェーン関連は継続

Googleの現行規則は、製品脆弱性に関する新規報告の受付を停止すると明記している。これは、Googleが公開するOSSの設計や実装に存在し、利用者データの機密性や完全性に重大な影響を及ぼす問題を扱うカテゴリだ。Googleが運営するすべての脆弱性報奨金制度を終了するわけではなく、OSS全般の脆弱性を受け付ける共通窓口が閉鎖されたわけでもない。

OSS VRPは2022年に始まった制度で、Googleが所有するGitHub組織の公開リポジトリなどを対象としている。今回、10月1日より前に提出された製品脆弱性の報告は停止の影響を受けない。また、Google Cloud製品に影響する一部のCloud関連リポジトリでは、別のCloud VRPで製品脆弱性の報告が受理される可能性がある。ただし、Cloudに関係するコードであれば何でもそちらへ移行できるという意味ではない。

引き続き受け付けるサプライチェーン関連の報告は、配布されるソフトウェアを誰が改変できるかという問題に関係する。例えば、リポジトリの主要ブランチを書き換えられる設定不備、利用者に配布されるビルド成果物を改ざんできる仕組み、パッケージ公開用の認証情報の漏えいなどだ。製品内部のコードそのものにある欠陥とは、攻撃される場所や経路が異なる。ソフトウェアサプライチェーンへの侵害につながる問題の報告は、現在も制度の対象として残っている。

ただし、サプライチェーンに関する指摘であれば無条件に報酬が支払われるわけではない。規則では、外部の投稿者が変更を取り込んでもらう際の承認手続きを迂回できるなど、実際の侵害につながる条件を満たすことが求められている。製品脆弱性の受付が止まったからといって、同じコード上の欠陥をサプライチェーン上の問題と言い換えれば受理されるわけではない。

春の品質要件強化から、10月の受付停止へ

GoogleのOSS VRPは、2026年春に製品脆弱性報告の対象範囲と証拠要件を厳しくし、10月1日には新規受付そのものを停止した。春の措置では、主要プロジェクトへの報告には検証可能な証拠を求め、優先度の低いプロジェクトについては製品脆弱性を報奨金の対象から外していた。10月の措置は、そこからさらに対象を広げ、製品脆弱性全体の新規受付を停止する変更となる。

春の規則改定ブログによると、AIが誤った発生条件を作り出した報告に加え、コード上にエラー自体は存在していても、そのプロジェクトのセキュリティ設計上ほとんど影響を及ぼさない報告が増えていたという。例として、攻撃者から到達できない処理で発生するバッファーオーバーフローなどが挙げられている。GoogleはAIがセキュリティ研究を支援する能力を認める一方、その出力は研究者自身が検証するよう求めていた。

Googleはプロジェクトを、主要なOT0、重要なOT1、標準のOT2、優先度の低いOT3に分類した。OT0・OT1におけるメモリ破壊の報告には、既存のOSS-Fuzzの検査対象を使った正確な再現手順、または対象リポジトリに取り込まれた修正が必要となった。一方、4月の追記では、OT2・OT3の製品脆弱性と「その他のセキュリティ問題」が、報奨金と公開クレジットの対象から外された。これら下位階層の製品脆弱性報告については、Googleのセキュリティチームが選別や検証を行わないとも説明している。

春のブログにある「April 2026 Update」「New Acceptance Criteria」と、現行規則の「Product vulnerabilities」を同じカテゴリごとに比較すると、変更点は次のようになる。

報告の区分・状態	2026年春の改定・4月追記	2026年10月1日以降
OT0・OT1の製品脆弱性	メモリ破壊にはOSS-Fuzzを使った正確な再現手順、または取り込み済みの修正が必要	製品脆弱性の新規受付を停止
OT2・OT3の製品脆弱性	報奨金・公開クレジットの対象外。Googleセキュリティチームは選別・検証を行わない	製品脆弱性の新規受付停止に含まれる
10月1日より前の提出分	提出時点の条件に基づいて扱われる	今回の停止による影響なし
サプライチェーンに関する報告	ソースやビルドの侵害、認証情報の漏えいを引き続き重視	今回の製品脆弱性受付停止の対象外

この比較は受付条件がどう変わったかを示すものであり、春の対策によって報告件数が何割減ったのかを示すものではない。再現要件についても、当時のOT0・OT1におけるメモリ破壊の報告に対する条件であり、すべての脆弱性について取り込み済みの修正を要求していたわけではない。Googleは、要件強化の効果を定量的に示したうえで今回の停止を説明しているわけではないため、「春の品質対策が機能しなかった」とまでは判断できない。

なぜ「再現できる」だけでは足りないのか

OSS-Fuzzの公式な再現手順では、問題を引き起こした入力ファイルを対象プログラムに与え、必要に応じてDockerを使ってビルド環境を揃える。メモリ破壊を調べる場合には、メモリへの不正アクセスを検出するAddressSanitizerなどを利用する。対象コード、入力、検出方法が揃っていれば、報告を読んだ別の人も同じ現象を再現しやすい。修正後に同じ入力を与え、問題が解消したかを確認することもできる。

AIがもっともらしい説明を生成しても、それだけでは実際にプログラムを動かして問題を確認した証拠にはならない。春の要件は、文章の説得力だけを根拠に報告を受理するのではなく、再現や修正の一部を報告者自身にも担ってもらう仕組みだったといえる。報告を受け取る側が、発生条件を最初から調べ直す負担を減らす狙いがあった。

それでも、プログラムが異常終了することと、利用者に実害が及ぶことは別の問題だ。攻撃者がその処理に入力を到達させられるのか、実際の利用環境でデータの機密性や完全性が損なわれるのかを見極める必要がある。Googleが春に例示した「攻撃者から到達できないコードのエラー」は、その違いを端的に示している。

現行規則では、ビルド可能な概念実証コードに加え、影響を受けるバージョン、再現手順、問題が及ぼす影響、攻撃が成立する条件の提示を求めている。修正がすでにリポジトリへ取り込まれていても、それだけで報酬が保証されるわけではない。コードを修正できたという事実と、報奨金の対象となるだけのセキュリティ上の影響を示したという事実は別だからだ。

curlでは低品質報告が減る一方、「本物の仕事」が増えた

curlは、報奨金制度を終了した後も、AIと脆弱性報告を巡る問題が続いた事例を示している。開発者のDaniel Stenberg氏は1月26日の説明で、2026年1月31日に報奨金制度を終了すると発表した。同氏によると、2025年には寄せられた報告のうち、実際の脆弱性だと確認できる割合が5%未満まで低下し、報告の真偽を見極める作業が時間と精神力を大きく消耗させていた。報奨金制度は終了したものの、脆弱性報告そのものの受付は続けた。

ところが、4月22日の報告では状況が変わっていた。同氏は、低品質なAI生成報告はもはや大きな問題ではなくなり、報告の品質が高まったと説明している。脆弱性だと確認される割合は15〜16%前後まで戻った一方、報告頻度は2025年の約2倍になったという。これはcurlに関するStenberg氏自身の報告であり、Googleの制度の状況を示す数値ではない。

Stenberg氏は、当時ほぼすべてのセキュリティ報告で何らかのAI支援が使われているともみていた。ただし、報告の文面や詳細な重複報告などを手掛かりにした推測であり、使用ツールを厳密に集計した結果ではない。少なくとも同氏の経験では、AIを利用した報告と高品質な報告は両立していた。

その先で問題となったのは、見つかった脆弱性を修正する人手の不足だった。同氏は、有効な報告が増えてもメンテナーが増えなければ、対応待ちの案件が積み上がると懸念している。低品質な報告を排除できれば、真偽の確認に費やす無駄な作業は減らせる。しかし、本物の脆弱性がより多く見つかれば、今度は修正やリリースに必要な作業が増える。curlの経験は、AI時代の報奨金制度を考えるうえで、報告の品質と、受け入れ側が処理できる量を分けて考える必要があることを示している。

再設計で見るべきなのは、報告から修正までにかかる負担

Googleは、2027年第1四半期にOSS VRPのこの部分について更新情報を出すとしている。ただし、その時期に受付を再開すると決めたわけではない。現在は、影響範囲に応じて利用できる他のVRPや、OSSのセキュリティ改善に報奨金を支払うPatch Rewards Programを案内している。研究者にとっては、発見した問題をどの制度へ報告できるのかが、当面の実務上の変更点となる。

今後の制度設計を評価するうえでは、AIの使用を認めるかどうかだけを見ても不十分だ。春のOSS-Fuzz要件のように、提出前の段階で再現確認を済ませる仕組みをどう組み込むのか。現実に攻撃が成立する条件や、セキュリティ上の影響を誰が確認するのか。そして、確認された問題を実際の修正につなげる作業に、研究者やメンテナーがどこまで関われるのか。報告件数を抑えることと、実際に修正できる件数を増やすことは、分けて評価する必要がある。

新たな条件によって、検証済みの入力や修正への貢献が促され、それを受け止められる人員や仕組みも整えば、AIによって増えた脆弱性の発見を、実際の安全性向上へつなげられる。Googleが2027年に示す更新では、どのような条件で報告を受け付けるのかだけでなく、確認された脆弱性を実際の修正につなげる仕組みがどこまで示されるかにも注目したい。