Google、OSSの脆弱性報告を一部停止――自動報告の急増で何が起きたのか

インターネット , , , , , , ,

Googleは2026年10月1日、オープンソースソフトウェアの報奨金制度「OSS VRP」で、製品の脆弱性に関する新規報告の受付を一時停止しました。脆弱性とは、情報の流出や不正な操作につながるソフトウェアの弱点です。［1］

停止したのは制度の一部です。Googleは、自動報告が急増し、その大多数が有効な報告ではないと説明しています。サプライチェーンに関する報告と、すでに提出された報告は、今回の停止の対象外です。［1］［2］

今回のニュースでは、AIがバグを探せるかに加え、大量の報告を確認して実際の修正につなげる体制が追いつくかも問われています。この記事では、公式ルール、過去の事例、独自の試算を分けて整理します。

※制度の説明は、2026年10月6日時点で確認した内容に基づきます。本文の試算は、Googleの報告件数や作業時間の実測値ではありません。

何が停止した？OSS全体の脆弱性報告が止まったわけではない

今回止まったのは、GoogleのOSS VRPを通じた「製品脆弱性」の新規受付です。OSSは、プログラムのソースコードを公開し、利用や改変を認めるソフトウェアを指します。OSS VRPは、そのうちGoogleが公開するOSSなどを対象とした脆弱性報奨金制度です。［1］

報告の種類・状況今回の扱い
OSS VRPへの製品脆弱性の新規報告2026年10月1日から受付を一時停止
10月1日より前に提出された製品脆弱性の報告今回の変更の影響を受けない
OSS VRPのサプライチェーンに関する報告今回の受付停止の対象外
Google Cloud製品に影響する一部のリポジトリの問題Cloud VRPで受け付ける場合がある
OSSの安全性を高める修正別制度のPatch Rewards Programを案内

出典：GoogleのOSS VRP公式ルールと、Googleの発表を掲載したSecurityWeek。別制度にも対象や条件があるため、すべての報告を別の窓口へ移せるわけではありません。［1］［2］

サプライチェーンの問題とは、ソフトウェアの開発・配布の過程にある、攻撃者に悪用されうる弱点です。たとえば、配布するプログラムを不正に差し替えられる問題が該当します。完成した製品の動作上の欠陥とは、調べる箇所も被害の広がり方も異なります。［1］

Googleが約束したのは、2027年第1四半期、つまり1〜3月に状況を改めて知らせることです。「その時期に必ず再開する」とは発表していません。［1］

自動報告が増えると、なぜ安全対策の負担になるのか

報告文を速く作れても、その内容が正しいかを確かめる作業まで同じ速さで進むとは限りません。報告を受ける側は、問題を再現し、攻撃が成立する条件を調べる必要があります。すでに修正された問題か、既存の報告と重複していないかも確認します。

Googleは2026年3月19日の公式説明で、AIが生成した報告の急増を指摘していました。問題が起きる条件をAIが誤って説明した報告や、コードに誤りがあっても実際の安全性への影響は小さい報告が増えたとしています。［3］

たとえば、メモリの扱いに問題があるように見えても、外部からその処理を実行できない場合があります。コードに問題があることと、攻撃者がその問題を利用して被害を与えられることは、それぞれ確認しなければなりません。［3］

これは、火災報知器の警報が大量に鳴る状況に似ています。警報が増えたからといって、火災が同じ割合で増えたとは限りません。ただし、誤報かどうかを判断するにも、人による確認が必要です。

10月の発表では「自動報告」という表現が使われています。3月の公式説明では、「AI生成報告」を明確に問題として挙げていました。これらの説明からAIの影響は読み取れますが、今回の自動報告がすべて生成AIによるものだったとは断定できません。［2］［3］

3月の証拠要件強化から、10月の受付停止へ

Googleは今回の停止以前から、脆弱性の疑いを示すだけの報告より、確認できる証拠を重視する方向へ制度を変えていました。3月の変更では、重要なプロジェクトに関する一部の報告で、再現手順や採用済みの修正を求めています。［3］

時期Googleが公表した変更読み取れる方針
2026年3月重要なプロジェクトのメモリ破壊の報告に、OSS-Fuzzでの正確な再現手順、または採用済みの修正を要求受け手が確認できる証拠を重視
2026年4月の追記下位区分のOT2・OT3では、製品脆弱性などへの報奨金と功績の掲載を対象外に審査する範囲を絞る
2026年10月1日OSS VRPの製品脆弱性の新規受付を一時停止受付方法そのものを見直す段階へ

出典：Google Bug Huntersの3月の説明と4月の追記、現行の公式ルール。OSS-Fuzzは、ソフトウェアにさまざまな入力を与えて不具合を探すGoogleの検査基盤です。メモリ破壊は、データを保存する領域を誤って読み書きする問題を指します。［3］［1］

この経緯を踏まえると、証拠の要求や対象の絞り込みだけでは対応しきれなかった可能性があります。ただし、確認した資料には、それぞれの変更で報告件数や確認時間が何％減ったかは示されていません。対策の効果を数値で断定することはできません。

curlの公表値から計算すると、確認の負担はどう変わる？

有効な報告の割合が15％から5％へ下がると、有効な1件を見つけるために確認する件数は3倍になります。これは割合から求めた計算で、Googleの実測値ではありません。

通信ツールのcurlは、2026年1月31日に報奨金制度を終了しました。開発者のDaniel Stenberg氏によると、以前は報告の15％超で脆弱性が確認されていましたが、2025年からは5％未満へ落ち込んだといいます。［4］

比較する有効率有効な1件当たりの報告件数各報告の確認に5分かかると仮定した時間
15％約6.7件約33.3分
5％20件100分

計算式は「1÷有効率」です。15％なら1÷0.15、5％なら1÷0.05となります。curlの公表値は「15％超」から「5％未満」なので、有効な1件当たりの報告件数は、実際には3倍を超えます。確認時間の比較では、1件当たりの作業時間が同じと仮定しています。

この計算は、有効な報告を1件見つけるまでに必ず20件調べるという意味ではありません。多数の報告をまとめて見たときの平均的な関係です。有効な報告と無効な報告で確認時間が異なれば、実際にかかる時間の比も変わります。

なお、curlは過去に、確認済みの脆弱性87件に対して合計10万ドル超の報奨金を支払っていました。報奨金制度が安全性の向上に役立った実績がある一方で、その後は報告を確認する負担が増えています。［4］

独自試算：1,000件の報告の確認に、どれだけの作業が必要か

報告件数だけを見ると成果が増えたようでも、確認する人の時間が足りなければ、未処理の報告が積み上がります。そこで、受付件数と作業時間の関係を仮の条件で計算します。

1週間に1,000件の報告が届き、1件の初期確認に平均5分かかると仮定します。有効率は5％、確認作業に使える時間は週40時間とします。いずれも説明用の数値で、Googleやcurlの実際の運営状況を表すものではありません。

項目計算試算結果
有効な報告1,000件×5％50件
無効な報告1,000件−50件950件
全件の初期確認にかかる時間1,000件×5分÷60約83.3時間
週40時間で初期確認できる件数40時間×60÷5分480件
その週に確認しきれない件数1,000件−480件520件

この条件では、初期確認だけで、作業に使える時間の約2.1倍が必要です。修正やテストの時間は含めていません。同じ状態で受付を続ければ、確認待ちの報告が毎週520件ずつ増えます。

次に、提出前の検証で「無効な950件のうち90％」を除外できたと仮定します。有効な50件をすべて残せれば、受け付ける報告は145件になります。初期確認は約12.1時間で済み、計算上の負担は85.5％減ります。

ただし、これは理想的な条件です。除外する仕組みの開発・運用にかかる時間も、計算には含めていません。検証が難しい本物の脆弱性まで除外すれば、受付の負担が軽くなっても、安全性は下がる可能性があります。

curl・Node.js・Anthropicと比べると、対策の違いが見える

「報奨金を止める」「報告窓口を止める」「検証と修正を支援する」は、それぞれ別の対策です。すべてを「AIのせいで脆弱性報告が終了した」とまとめると、実際の影響を見誤ります。

組織・制度公表された対応Googleとの比較点
Google OSS VRP製品脆弱性の新規受付を一時停止特定の報告経路を見直す
curl金銭による報奨を終了。GitHubの非公開報告などで受付を継続報告窓口を残し、報酬の仕組みを変える
Node.js外部資金の停止により報奨金を休止。報告受付と審査は継続直接の理由は資金の停止。低品質な報告への対応とは分けて考える必要がある
AnthropicClaude Securityで検査・修正案の作成を支援し、OSS向けに3,500万ドル分の利用クレジットを発表発見に加え、修正も支援。ただし人による確認は必要

出典：Google公式ルール、curl開発者の説明、Node.js公式発表、Anthropic公式発表。制度の違いを比較したもので、成果や安全性を順位付けするものではありません。［1］［4］［5］［6］

Anthropicが2026年8月21日に発表した3,500万ドルは、現金ではなくClaudeの利用クレジットです。脆弱性の修正や、検査・修正の自動化を支援するとしています。Claude Securityが提案する修正も、実施前に人が確認し、承認する仕組みです。［6］

利用クレジットがあれば、AIを使う費用を抑えられます。しかし、それだけで保守担当者が作業に使える時間や給与が増えるわけではありません。受付を絞る対策と、修正する側の人員・資金を支える対策は、組み合わせて考える必要があります。

反証：AIを使うこと自体が、無効な報告の原因なのか

AIを使った報告でも、問題を再現でき、被害につながる条件を示せれば、安全対策に役立ちます。Google自身も3月の説明で、AIは脆弱性調査を効率化する強力な道具だと認めたうえで、出力の検証が必要だと説明しています。［3］

今回の停止は、「AIによる脆弱性調査はすべて無意味」という証拠にはなりません。問題なのは、候補を見つけた段階で調査を止め、確認を受け手に丸ごと任せてしまうことです。人が作った報告でも、同じ状態なら負担になります。

受付停止にも不利益はあります。実際に脆弱性を見つけた研究者が報告先を探し直す必要が生じ、重要な情報が届きにくくなる可能性があります。Googleの判断を評価する際は、誤報を減らす効果と、本物の報告を失うリスクの両方を見る必要があります。

curl開発者が比較した同じグループのRuby、Node、Railsでは、当時の報告件数はおおむね横ばいか減少していました。curlほどの増加が、すべてのOSSで起きていたわけではありません。報酬、知名度、対象となるコードなどによって差が出る可能性はありますが、原因は確定していません。［4］

制度見直しの評価では「有効率」だけを見ない

有効率が上がっても、本物の脆弱性の発見数が減っていれば、改善したとは言い切れません。今後の制度を評価する際にも、この点を考慮する必要があります。

たとえば、次の二つの週を比べます。以下は仕組みを説明するための架空の例で、Googleが公開した実績ではありません。

架空の状況受け付けた報告有効な報告有効率
受付を絞る前1,000件50件5％
受付を絞った後200件40件20％

有効率は4倍になっていますが、有効な報告の数は20％減っています。減った10件が重要な問題なら、有効率の上昇だけを喜ぶことはできません。逆に、重要な問題をより早く修正できていれば、件数が少なくても意味があります。

本記事では、制度見直しの評価項目として「確認にかかった総時間」「確認済みの重要な脆弱性の数」「報告から修正までの時間」「除外後の再審査で有効と認められた報告の数」の四つを提案します。複数の指標を使い、負担と安全性を併せて評価するためです。

Googleがどの指標を公開するかは、現時点では分かりません。2027年1〜3月に状況が更新される際は、受付方法に加え、こうした結果も示されるかが注目されます。

一般利用者・WordPress運営者は何をすればよい？

このニュースだけを理由にOSSの利用をやめる必要はありません。まずは、使っている製品の更新情報と、自分の環境への影響を確認してください。今回の変更は報奨金制度の受付に関するもので、特定の製品が新たに危険になったという発表ではありません。

WordPressなどでサイトを運営する人は、制度変更のニュースと、自分のサイトに関係する脆弱性情報を分けて考えると判断しやすくなります。次の表は、今回の問題を踏まえ、本記事で提案するサイト運営者向けの確認項目です。

届いた情報最初に確認すること次の対応
利用中の製品の公式セキュリティ告知対象バージョンと修正版の有無自分の環境が対象なら、影響に応じて更新を優先する
プラグインやテーマについての外部記事製品名・提供元・バージョンが自分の環境と一致するか提供元の告知と照合して判断する
AIが作った脆弱性診断文問題箇所、再現条件、実際の結果、根拠が示されているか診断文だけで侵害されたと決めつけず、開発元や担当者へ確認する
Google OSS VRPの受付停止ニュース制度の変更なのか、利用中の製品の欠陥情報なのかこのニュース自体を製品の緊急更新通知として扱わない

WordPress本体の公式資料では、更新前のバックアップを案内しています。ファイルに加え、データベースも復元できるよう準備を確認してください。更新方法は、利用しているサーバーや製品の案内に従うのが基本です。［7］

開発者や研究者は、報告前に対象のバージョン、再現手順、観測した結果、実際の安全性への影響を整理しておくとよいでしょう。AIの推測と、手元で確認した事実も分けて記載してください。別制度の対象になるかは、最新の公式ルールで確認する必要があります。

まとめ：発見数より、修正につながる報告が重要になる

今回の停止から見えてくるのは、脆弱性の候補を大量に見つける能力と、それを検証して安全な修正につなげる能力の間にある差です。GoogleはOSS VRPの製品脆弱性の新規受付を止めましたが、サプライチェーンに関する報告などは、今回の停止の対象外です。

独自計算からは、有効率が下がるだけでも、確認の負担が大きく増えることが分かります。一方、受付条件を厳しくしすぎれば、本物の発見を失う恐れもあります。制度を評価するには、報告件数や有効率に加え、重要な問題をどれだけ早く修正できたかを見る必要があります。

一般利用者は、使っている製品の公式情報を確認し、必要な更新を行ってください。OSS全般への不安を広げても、具体的な安全対策にはつながりません。研究者には、もっともらしい説明を増やすよりも、他の人が確認できる証拠を届ける姿勢が求められます。

関連ページ

AIによる脆弱性調査を理解するには、検査・修正の支援と、実際に攻撃が成立する経路の検証を分けて読むと整理しやすくなります。

参考資料

制度の対象や受付方法は変わる可能性があるため、報告前には最新の公式ルールを確認してください。

  1. Google：OSS VRP公式ルール（公式GitHub公開版）／Google Bug Huntersの制度ページ
  2. SecurityWeek：Google Narrows Open Source Bug Bounty Amid Wave of Invalid Automated Reports（2026年10月5日。Googleの10月1日の発表文を掲載。Xの原投稿本文は本記事の調査環境では取得できなかったため、停止範囲は公式ルールで確認し、停止理由の発表文は同報道と照合）
  3. Google：Streamlining Google’s OSS VRP: Key Rule Updates（2026年3月19日、4月の追記を含む）
  4. Daniel Stenberg：The end of the curl bug-bounty（2026年1月26日）
  5. Node.js：Security Bug Bounty Program Paused Due to Loss of Funding（2026年4月2日）
  6. Anthropic：Bringing the cybersecurity capabilities of Claude Mythos 5 to more defenders（2026年8月21日）
  7. WordPress：Updating WordPress

タグ

Related Posts

コメントを送信

You May Have Missed