Google OSS VRPの停止が示す、AIバグ報告における検証の問題
Googleは10月1日、無効なAI報告が審査プロセスを圧迫していると報じられたことを受け、オープンソース脆弱性プログラムの一部カテゴリーを停止した。
Google OSS VRPの停止により、同社がプログラムの当該部分を再設計する間、新たな「Product Vulnerability」報告の受け付けが止まる。Googleは2027年第1四半期中に最新情報を提供する見込みだ。
この決定は、Googleの脆弱性プログラムすべてを閉鎖するものではない。また、研究者によるコード調査での人工知能の利用を禁止するものでもない。
むしろ、これは自動化された発見と人間による検証の間で広がる対立を浮き彫りにしている。AIは、メンテナーが再現、評価、修正できる速度をはるかに上回って、潜在的な問題を生成できる。
Googleの対応は、オープンソースセキュリティ全体で数カ月にわたり高まってきた圧力に続くものだ。Linuxのメンテナーや他のプロジェクトも、重複した、推測的な、あるいは十分に検証されていない報告の同様の波に直面してきた。
このより大きなパターンは、1つの報告フォームが停止されたこと以上に重要だ。セキュリティプログラムは従来、社内チームが見落とした問題を発見した研究者に報いる仕組みだった。AIは、候補の生成を異例なほど低コストにすることで、このモデルを変えている。
希少な資源は、もはや最初の疑念ではない。欠陥が到達可能で、悪用可能で、現実の脅威モデルに関連することを証明するために必要な専門家の注意力だ。
Google OSS VRPの停止で実際に変わること
Googleは1つの報告カテゴリーを停止したのであって、オープンソースの脆弱性研究を放棄したわけでも、バウンティ運営全体を閉鎖したわけでもない。
OSS VRPとして知られるOpen Source Software Vulnerability Reward Programは、Googleが所有するオープンソースリポジトリにおける対象となるセキュリティ問題を扱う。Googleは2022年にこのプログラムを導入した。
製品脆弱性報告は、プロジェクトのコード、ロジック、または設計に含まれる欠陥を指摘するものだ。有効な報告は、疑わしいコードを示すだけでは足りない。
研究者は一般に、影響を受けるバージョン、到達可能な実行経路、再現手順、そして意味のあるセキュリティ上の影響を示す必要がある。こうした要件は、悪用可能な脆弱性と通常のプログラミングミスを区別する。
suspension detailsによると、この停止はGoogleが10月1日に発表した時点で発効した。それ以前に提出された製品脆弱性報告は引き続き審査対象となる。
サプライチェーン報告も引き続き受け付けられている。これらは、ソフトウェア依存関係、ソースコード、ビルド、またはリリースがユーザーに届く経路に影響する侵害に関する報告だ。
Google Cloud製品に影響する一部の脆弱性は、別途設けられたCloud VRPを通じて引き続き対象となる可能性がある。対象かどうかは、リポジトリと対象クラウド製品との関係によって決まる。
研究者はGoogleの他の報奨プログラムにも参加できる。これにはChrome、Android、Googleデバイス、クラウドサービス、専用のAIセキュリティ問題を対象とするプログラムが含まれる。
この対象範囲の違いは重要だ。この措置を全面的な閉鎖と呼べば、出来事を誇張し、より的を絞ったGoogleの対応を見えにくくしてしまう。
同社は実質的に、高ボリュームの受け付け経路を閉じる一方、より限定的なチャネルは残している。今後について議論する前に、この経路を再編する計画だ。
具体的な代替策はまだ分かっていない。Googleは、本人確認、再現、報告頻度、証拠に関する要件を強化するかどうかを公表していない。
Googleは停止前からプログラムを厳格化していた。OSS VRP rulesでは、研究者に対し、AI支援による発見を検証し、実際のセキュリティ影響を実証することを求めていた。
規則では、繰り返し発生する問題がいくつか説明されていた。AI生成の報告には、不正確な発火条件や、創作された技術的詳細が含まれるものがあった。
別の報告では、実在するコーディングエラーを特定していても、セキュリティ上の影響を立証できていなかった。例えばバッファオーバーフローが存在していても、それは到達不能なコード内にしか存在しない、あるいは有効なセキュリティ境界の背後にある可能性がある。
Googleはまた、一部の低優先度の製品脆弱性やその他のセキュリティ問題について、金銭的報酬と公開クレジットを終了した。この2026年4月の変更は、影響度の低い報告へのインセンティブを取り除こうとする試みだった。
その後の停止は、こうした限定的な対策では審査負担を十分に減らせなかったことを示唆している。Googleは、弱い報告を抑制する段階から、当該カテゴリーを一時的に受け付けない段階へと移行した。
したがってGoogle OSS VRPの停止は、運用上の判断を表している。プログラムの審査担当者は、提出されるあらゆる可能性を、手頃な出発点として扱い続けることができなくなった。
AIバグ報告は主張を行うコストを変えた
AIは脆弱性を主張するコストを下げる一方、それを証明するコストは下げない。
従来の脆弱性研究では、研究者がもっともらしい報告を作成する前に、相当な手作業が必要だった。研究者はコードを調べ、実行経路を理解し、テストを構築しなければならなかった。
現代の言語モデルや自律型コードエージェントは、リポジトリを走査し、仮説をはるかに高速に生成できる。また、慎重な人間の分析に見える洗練された報告書も作成できる。
その見た目は危険な非対称性を生む。説得力のある文書は数秒で生成できる一方、その主張を反証するには専門家の注意を何時間も要することがある。
ある報告は、不審なメモリ操作を特定し、リモートコード実行を予測するかもしれない。モデルはその予測を軸に、詳細な攻撃シナリオを作成できる。
しかし、影響を受ける関数が攻撃者の制御下にある入力を処理することはないかもしれない。コンパイラがその経路を除去する可能性もあり、既存の検証が提案されたトリガーを阻止する可能性もある。
プロジェクトの脅威モデルが、想定された攻撃者権限を対象外としている場合もある。いずれの場合も、報告は深刻に聞こえる一方で、脆弱性を実証できていない。
メンテナーは、自動化された報告を一見してすべて安全に却下することはできない。不十分に書かれた提出物にも実際の欠陥が含まれる可能性があり、洗練された提出物が完全に推測に基づく場合もある。
審査担当者はコードを調べ、環境を再現し、主張された入力をテストし、既存の防御策を評価しなければならない。証拠が不足していれば、報告者に連絡する必要が生じることもある。
この負荷は、無効なものを含め、報告が増えるたびに大きくなる。したがって自動化された提出は、検証コストを報告者からメンテナーへ移転する。
この影響は、従来のセキュリティ研究というよりメールスパムに似ている。もう1通送るコストはほとんどかからないが、受信側の組織は重要である可能性を持つ各主張を依然として選別しなければならない。
金銭的報酬はこの不均衡を強める可能性がある。1件の採用結果が数千件の提出を生成するコストを賄えるなら、弱い参加者にとって量を増やすことは合理的な戦略になる。
この行動は、慎重な作業を行う研究者を害する。彼らの発見は同じキューに入り、同じ審査担当者の注意を奪い合う。
また、メンテナーが確認済みの脆弱性を修正する時間を減らす場合、ユーザーにも害が及ぶ。修正を始める前段階で、トリアージがボトルネックとなる。
問題は、単にモデルがハルシネーションを起こすことではない。人間の研究者も誤りを犯し、影響を過大評価し、重複報告を提出する。
AIは、こうした失敗の規模、速度、見せ方を変える。個人が自ら検証できる数を超える、もっともらしい主張を生み出せるようになる。
この違いは、AI生成の文章を禁止してもほとんど解決にならない理由を説明する。研究者は未検証のモデル出力を書き直し、同じ根拠のない主張を提出できる。
その代わりにプログラムには、証拠に基づくゲートが必要だ。重要なのは、モデルが発見に寄与したかではなく、報告者が結果をテストしたかどうかである。
Googleの停止は、既存の規則ではその違いを効率的に徹底できなかったことを示している。文書化された要件は公表するよりも、工業化された規模の報告量に対して適用するほうが難しかった。
GoogleのAIセキュリティ戦略は新たなトレードオフに直面している
GoogleはAI支援によるセキュリティ発見を推進しているが、その報奨プログラムは同じ自動化の波が生み出すすべての発見を受け止められない。
Google OSS VRPの停止は、同社がAIをセキュリティに役立たないと考えていることを意味しない。Googleは引き続き、自動化された脆弱性発見と修正に投資している。
同社のセキュリティチームは、OSS-Fuzz、Big Sleep、CodeMenderなどのツールを使用している。これらのシステムは、自動化された分析と、制御されたテスト、専門家によるレビューを組み合わせる。
Googleはまた、同社がAI時代と呼ぶ状況に合わせて、AndroidとChromeの報奨プログラムを再設計している。同社は、自動化によって従来の研究が見落とす脆弱性が発見されると見込んでいる。
それゆえ、この停止は意味のある方向転換だ。GoogleはAIセキュリティ研究から後退しているのではなく、AIによる提出コストの低下の影響を受けた外部チャネルを制限している。
中心となる区分は、人間による研究と機械による研究の対立ではない。社内で検証された自動化と、検証の度合いが一定でない外部提出の主張との違いだ。
Googleは自社システムを取り巻く環境を管理している。エンジニアは対象を定義し、テストを実行し、クラッシュを収集し、生成されたパッチが動作を維持するかを測定できる。
オープンな報奨プログラムには、そのような制御がない。参加者は異なるツール、プロンプト、モデル、コードバージョン、セキュリティ影響の定義を使用する。
審査担当者が受け取るのは、そこに至るすべての手順を確認できない最終的な主張だ。発見に意味があるかを判断する前に、欠けた前提を再構築しなければならない。
この違いにより、来歴は実務上のセキュリティ問題となる。チームは、どのリビジョンがテストされたのか、どの入力が結果を引き起こしたのか、人間が再現したのかを知る必要がある。
Googleのより広範な報奨システムは依然として大規模だ。同社によると、そのプログラムは2025年中に700人以上の研究者に総額1,700万ドル超を支払った。
annual VRP reviewでは、この総額を過去最高と説明している。金額は2024年から40％以上増加した。
これらの数字は、Googleが外部研究を今も重視していることを示している。同時に、信頼できる提出チャネルを維持することがなぜ重要なのかも示している。
バウンティプログラムは相互の信頼に依存する。研究者は有効な発見が公正に扱われると信じる必要があり、企業は報告者が自らの主張を検証したと信頼しなければならない。
無差別な自動化は双方を弱める。審査の遅延は有能な研究者を苛立たせ、無効な報告が繰り返されると、審査担当者は初めての貢献者により懐疑的になる。
Googleの対応はトリアージ能力を守るが、アクセスも狭める。独立研究者は現在、停止されたOSS VRPカテゴリーを通じて通常の製品脆弱性を提出できない。
この制約は、ノイズとともに価値ある発見まで抑制する可能性がある。有効な問題を見つけた新しい研究者には、明確な代替プログラムがないかもしれない。
したがって課題は、開放性と検証の間のトレードオフだ。幅広いアクセスは発見の機会を増やす一方、厳格なゲートは限られた審査担当者の時間を守る。
再設計されるプログラムは、両方の目標を維持しなければならない。参加要件が過度に負担となれば、Googleは参加を既存の研究者や専門企業に集中させるリスクを負う。
要件が緩すぎれば、提出キューは再び同じ過負荷に戻りうる。2027年第1四半期の更新で、Googleがどこに線を引くかが明らかになる。
AI報告の洪水は業界全体の問題
Googleの決定は、セキュリティコミュニティが自動化された発見に合わせて開示ルールを書き換えている、より広範な変化の一部である。
HackerOneは、より高性能なAIツールが2026年2月に登場した後、業界の報告件数が100％を超えて増加したと報告した。
同社の報告件数分析では、一部の提出には有用な発見が含まれていた一方、重複、検証不能な主張、または実行可能な深さを欠く報告もあったことが示された。
同プラットフォームは、責任あるAI支援を禁止する対応は取らなかった。その代わり、発見を検証し、実際の影響を示すという研究者の義務を強化した。
HackerOneのルールでは、再現可能な概念実証、正確な深刻度評価、既存の防御策の考慮が求められる。未検証の報告を大量に提出すると、措置の対象となる可能性がある。
このアプローチでは、ツールではなく運用者に説明責任が置かれる。研究者は、生成されたすべてのエンドポイント、攻撃手順、影響に関する主張に引き続き責任を負う。
Linuxカーネルコミュニティも、同様に証拠重視のアプローチを取っている。同コミュニティのセキュリティ報告ルールは現在、AI支援によるコードレビューに直接言及している。
ドキュメントでは、AIによる報告は過度に長くなり、重要な事実を見えにくくしがちだと述べている。報告者には、簡潔な説明、影響を受けるリビジョン、発生条件、テスト済みの再現手順を提供するよう求めている。
Linuxはまた、ツールがカーネルの脅威モデルを理解しないまま、理論上の影響を作り出す可能性があると警告している。その代わりに、検証可能な結果を示すよう報告者に求めている。
このプロジェクトは、広く再現可能な自動検出結果を、従来は非公開で扱われてきた発見とは異なるものとして扱う。同様のツールを実行するため、複数の研究者が同じ問題を見つけることが多い。
これは、希少で独自に発見された脆弱性を前提に設計された開示チャネル内で重複作業を生む。自動化は、そうしたチャネルを支える前提を変えている。
CurlのメンテナーであるDaniel Stenbergは、2025年にこの問題の別の側面を説明した。彼の「death by a thousand slops」という主張は、質の低い提出をレビューする累積コストに焦点を当てたものだ。
1件の悪い報告であれば、対処可能に見えるかもしれない。しかし、そのコストが数百件の生成された主張にわたって繰り返されれば、ボランティア運営のプロジェクトは疲弊しかねない。
これらの事例には共通する仕組みがある。AIは、脆弱性仮説の供給を、有資格のトリアージ作業力の供給より速く拡大する。
影響は組織によって異なる。Googleは有給のセキュリティエンジニアを配置できる一方、小規模なプロジェクトは限られた時間のボランティアに依存することが多い。
オープンソースのメンテナーは、特に難しいインセンティブ構造に直面している。公開コードは自動スキャナーが取り込みやすいが、メンテナーにはそれに見合うリソースが提供されない。
報奨金は別の不均衡を加える可能性がある。企業は受理された発見に報奨を支払う一方、コミュニティのメンテナーは補償なしに初期の議論やアップストリームでの修正を担う場合がある。
これは、自動化された調査が本質的に有害だという意味ではない。AIは、目立たないコンポーネントを調査し、不慣れなコードを翻訳し、研究者によるテスト作成を支援できる。
検証後に利用すれば、報告の品質を高めることもできる。モデルは再現手順を整理したり、複雑な制御フローをより明確に説明したりできる。
同じ能力でも、検証に取って代わると破壊的になり得る。もっともらしい説明を生成することは、悪用可能な状態を実証することと同じではない。
そのため、業界で形成されつつある合意は条件付きの受容だ。人間の運用者が重要な主張をすべて再現し、裏付けられる場合に限り、AI支援は引き続き歓迎される。
Googleの一時的な閉鎖は、この原則よりも制限的だ。しかし、責任をどこに置くべきかという点では、同じ判断を反映している。
報告を提出する人物は、受信者を守るために十分な検証コストを負担しなければならない。そうでなければ、プログラムは推測的な機械出力のための外部委託テストキューとなる。
より強いゲートは役立つが、新たなリスクも生む
再設計されたプログラムでは、正当な独立研究者を排除せず、検証コストをすべての提出に織り込む必要がある。
Googleは、製品脆弱性の提出に代わる最終的な仕組みを明らかにしていない。ただし、いくつかの対策は、以前のルールで特定された問題に適合するだろう。
第一は、テスト済みの再現手順を必須にすることだ。再現手順は、主張された挙動を一貫して引き起こす小さなプログラム、入力、または手順を提供する。
Googleは、報告者に正確なリポジトリのリビジョンと環境を明記させることができる。この情報により、古いコードや互換性のないコードをテストする時間の損失を減らせる。
報告には、明示的な到達可能性の論証を求めることもできる。報告者は、攻撃者が制御するデータが脆弱な操作にどのように到達するかを示す必要がある。
構造化された脅威モデルの項目は、研究者に必要な権限、信頼境界、既存の緩和策を特定させることができる。裏付けのない深刻度の主張も、見つけやすくなる。
レート制限も別の選択肢だ。Googleは、一定期間内に1つのアカウントが提出できる未解決の報告件数を制限できる。
これにより、慎重な研究者のアクセスを維持しつつ、無差別な提出を抑制できる。受理された実績に応じて、より高い上限を設定することも可能だ。
デポジットや評判に関する要件は、より強力なフィルタリングを提供できるが、公平性に関するリスクも大きい。新しい研究者はプログラムへの参加が難しくなるかもしれない。
自動の事前スクリーニングも、もう1つの有力な構成要素だ。Googleは、静的解析、サンドボックス実行、またはモデルベースのレビューを用いて、重複や不足する証拠を検出できる。
ただし、自動スクリーニングが最終的な権威になることは安全ではない。異例だが有効な調査を却下したり、よく知られた脆弱性パターンを優遇したりする可能性がある。
あるモデルが別のモデルの報告をレビューする場合、同じ誤った前提を再現する可能性もある。独立した実行証拠は、テキスト上の一致よりも引き続き価値が高い。
プライバシーと機密性は、さらに複雑な問題を生む。研究者は、モデルに分析を求める際、未修正の詳細を第三者のAIサービスに公開する可能性がある。
改訂されたプログラムでは、機密性の高い発見に関する外部モデルの利用を開示するよう求めることができる。また、どの機密資料をホスト型システムに入力できるかを制限することも可能だ。
Googleは、オープンソースのメンテナーがトリアージにどのように参加するかも明確にしなければならない。報告はGoogleのリポジトリに影響を及ぼす一方、より広範な貢献者コミュニティに作業を課す可能性がある。
同社は、キューの問題を検証義務のアップストリームへの移転によって解決するべきではない。それでは負担を減らすのではなく、別の場所へ移すだけになる。
一時停止の期間中、透明性が重要になる。Googleは、受理、重複、無効、AI支援の各報告について、詳細な内訳を公表していない。
Tom’s Hardwareは、エンジニアとメンテナーが何千件もの質の低い提出に直面していると報じた。しかしGoogleの公表通知には、正確な件数や受理率は示されていなかった。
この違いは、外部の人々が導ける結論を制限する。利用可能な証拠は深刻な品質問題を裏付けているが、完全な定量的全体像を示すものではない。
Googleは、再設計されたしきい値を説明するのに十分な集計データを公表すべきだ。有用な指標には、レビュー時間の中央値や、動作する再現手順を欠く報告の割合が含まれる。
誤却下率も重要だ。自動フィルターが強力な発見を誤分類して消してしまうなら、キューが速くなっても成功とは言えない。
プログラムは、発見支援と自律的な提出を区別すべきだ。人間がレビューしたAIの発見は価値を持ち得る一方、監督のない報告パイプラインは管理不能なリスクを生む。
Googleの最も強力な設計は、文章よりも証明を評価しやすくするものだ。機械可読なテスト、制約付きテンプレート、再現可能な環境が、その目標を支えられる。
同社は、非従来的な発見のためのエスカレーション経路も維持すべきだ。重要な脆弱性の中には、単純なテストケースに収まらなかったり、複雑な連鎖を伴ったりするものがある。
単一のゲートで、これらの要件の均衡を取ることはできない。考えられる答えは、証拠の品質、研究者の実績、実証されたセキュリティ上の影響に基づく多層的なアクセスだ。
Googleの2027年第1四半期アップデートまでに注目すべき点
次の段階では、Googleが単に受け入れる研究者を減らすのではなく、より良い証拠基準で提出を再開できるかが明らかになる。
最初のシグナルは、代替プログラムの範囲だ。Googleは、製品脆弱性の提出を全面的に再開するのか、それともより狭いチャネルを通じて戻すのかを説明しなければならない。
全面的な再開は、新しいフィルターがレビュー工程への信頼を回復したことを示すだろう。限定的な招待制度であれば、トリアージ能力が依然として制約されていることを示す。
2つ目のシグナルは、報告者に求められる証拠だ。テスト済みの再現手順、影響を受けるコミット、具体的な攻撃経路は、Googleがすでに特定した弱点に対応する。
これらの要件は、アクセス可能な状態に保たれるならプログラムを強化する。不透明なレビュー基準を満たせるのが確立された研究者だけなら、逆に弱体化させる。
3つ目のシグナルは、他のセキュリティプログラムがどのように対応するかだ。HackerOne、Linux、主要ベンダーはいずれも、AIを意識した提出ルールを試行している。
再現性と人間の説明責任に収束すれば、業界は共通の基準線を形成する可能性がある。それにより、複数のプログラムで活動する研究者の混乱を減らせる。
一方、プログラムごとに互換性のない制限を採用すれば、開示はより困難になる。研究者は、標的ごとに異なる証拠パッケージ、AIポリシー、機密保持の実務を必要とするかもしれない。
開発者はツールそのものにも注目すべきだ。より優れたエージェントは動作するテストを作れるが、より高い確信をもって無効な証拠を生成することもある。
重要な基準は、エージェントがどれだけ多くの警告を見つけるかではない。専門家のレビューを経て、独立して再現可能で、セキュリティに関連する発見がどれだけ残るかだ。
メンテナーは、生の提出件数ではなく、受理された脆弱性1件あたりの所要時間を追跡すべきだ。この指標は、自動化がセキュリティを改善しているのか、それとも単にキューを拡大しているだけなのかを捉える。
研究チームは、AI支援作業のすべての段階を文書化することで準備できる。テストしたコミット、設定、ログ、入力、再現に失敗した試行を保存する。
チームには、過去の発見を検索できる記録も必要だ。構造化されたエンジニアリングナレッジベースは、問題がメンテナーに届く前に重複を特定するのに役立つ。
研究者は、生成された文章に頼らずに欠陥を説明できるべきだ。なぜコードパスに到達可能なのか、既存のどの制御が機能しないのかを理解している必要がある。
その説明が欠けているなら、その発見はまだ仮説にすぎない。脆弱性報奨プログラムに提出する準備はできていない。
したがって、Google OSS VRPの停止は、AIセキュリティ研究への否定的な判断ではなく、ワークフロー設計に関する警告だ。発見は加速したが、検証が不要になったわけではない。
Googleの2027年第1四半期アップデートは、大手ベンダーがこの現実を軸にオープンプログラムを再構築できるかを試すことになる。最良の結果は、提出数を最大化することではない。
レビュアーの注意を1時間使うあたりの、検証済みセキュリティ価値を最大化することだ。この基準は、真摯な研究者に明確な目標を与え、メンテナーを推測的な大量提出から守る。
AI支援による発見をどこかに提出する前に、3つの問いを投げかけるべきだ。他者が再現できるか、実際のセキュリティ境界を越えるか、そして主要な主張をすべてテストしたか。
いずれかの答えが「いいえ」なら、調査を続けるべきだ。最も安価に生成できる報告が、メンテナーにとって最も反証コストの高いものになる可能性がある。
