AIレポートが審査担当者を圧倒し、Googleのオープンソース・バグ報奨金制度が一時停止
Googleは、自動生成されたレポートの急増を受けてオープンソースのバグ報奨金制度を一時停止した。大半が無効だったという。停止は2026年10月1日に始まり、Open Source Software Vulnerability Reward Programへの新規プロダクト脆弱性報告が対象となる。
この決定は、AI支援型セキュリティ調査の鮮明な矛盾を浮き彫りにする。モデルは今や、これまでにない速度でより多くのコードを調査し、もっともらしいレポートを作成できる。しかし、主張された脆弱性が実在するか、重要か、再現可能かを判断するには、依然として一件ごとに人の確認が必要だ。
Googleだけではない。Curlは、確認済み脆弱性の比率が2025年に5%未満へ低下した後、金銭的な報奨金を終了した。Linuxのメンテナーも、重複したAI由来の発見が大量に届いたことを受け、開示の運用を変更している。これらの事例は、脆弱性の発見能力が脆弱性レビュー能力を上回る速度で拡大したことを示している。
Googleのオープンソース・バグ報奨金制度、新規プロダクト報告の受け付けを停止
Googleは、自動化された投稿が有用なセキュリティ上の発見を上回るレビュー作業を生んだため、主要な受け付け窓口の一つを一時的に閉鎖した。
Google OSS VRPは、Open Source Software Vulnerability Reward Programの略で、対象となるオープンソースプロジェクトのセキュリティ上の欠陥を責任を持って開示した研究者に報奨を提供する。Googleは、公開リポジトリ内で保守するソフトウェアと、選定した外部プロジェクトを対象にするため、2022年にこの制度を開始した。
このプロダクト脆弱性の窓口は10月1日、新規レポートの受け付けを停止した。Googleは、2027年第1四半期中に次の更新情報を提供する見込みだとしている。
「この一時停止は、自動化された投稿の著しい増加によるものであり、その大多数は有効ではありません」とGoogleは通知で述べた。この表現は、自動化と検証済みの脆弱性調査を区別している点で重要だ。
この一時停止によって、締め切り前に提出されたレポートが消えるわけではない。また、より広範なプログラムに関連するすべての経路を閉じるものでもない。更新されたプログラム規則によれば、サプライチェーン脆弱性の報告は引き続き対象となる。
Google Cloudのリポジトリに関わる一部の脆弱性は、Cloud VRPを通じて引き続き対象となる可能性がある。Googleはまた、オープンソースの受け付けプロセスを見直す間、他の報奨金プログラムを利用するよう研究者に案内している。
この限定的な対象範囲を踏まえると、「停止」よりも「凍結」という表現が正確だ。GoogleはOSSプログラム内の新規プロダクト脆弱性報告を停止したのであって、全社的な外部セキュリティ調査を放棄したわけではない。
同社は、対象窓口の投稿件数、無効レポート率、またはトリアージの総滞留件数を公表していない。そのため、審査担当者が具体的な件数の不正確なレポートを受け取ったという主張は、依然として裏付けられていない。
Googleが開示したのは決定的な兆候である。自動化されたレポートは、既存プロセスを持続不可能にするほど大量で、かつ信頼性に欠けるものとなっていた。
そのプロセスは、整った文書を受け取るだけでは済まない。審査担当者はコードパスを調べ、条件を再現し、悪用可能性を判断し、重複を検索し、責任を持つプロジェクトチームを特定しなければならない。
もっともらしいレポートは、誤っていた場合でも多大な時間を消費し得る。大規模言語モデルは、根本となる脆弱性を証明せずに、詳細な説明、コードスニペット、確信に満ちた深刻度の主張を生成できるため、この問題をより難しくしている。
Googleはすでに、AI生成レポートの「大規模な急増」を確認した後、2026年の早い段階で規則を厳格化していた。10月の一時停止は、フィルタリング要件だけでは許容可能な信号対雑音比を回復できなかったことを示唆する。
このため、Googleのオープンソース・バグ報奨金制度は、より広範なセキュリティ問題の試金石となった。主張を生成するコストは今や低い一方で、その主張を反証するコストは依然として高い。
AIバグレポートが生む非対称なコスト
AIは、メンテナーが検証できる速度を上回ってレポートを生成できるため、開示の経済性を変えている。
従来のバグハンティングは、研究者に相応のコストを課す。人はコードベースを理解し、予期しない挙動を切り分け、それがセキュリティ上の影響につながるかを検証し、再現可能な事例として文書化しなければならない。
生成AIは、その作業の一部を軽減する。エージェントはリポジトリを走査し、関数を追跡し、パターンを比較し、概念実証コードを下書きし、予備的な発見を専門的に見えるレポートへとまとめられる。
こうした能力は、正当な研究者の助けになり得る。一方で、経験の浅い利用者が、理解もできず、追加質問にも答えられない主張を提出することも可能にする。
非対称性は提出後に現れる。もう一件のレポートを作成するのに追加の労力はほとんど要らないかもしれないが、そのトリアージには依然として貴重なエンジニアリング上の注意力が必要となる。
Open Source Security Foundationの最高技術責任者であるChristopher Robinsonは、3月のセキュリティレポートでこの負担を説明した。人気プロジェクトは以前、平均的な週に2件か3件のレポートを受け取っていたと同氏は見積もる。その後、一度に数百件を受け取るケースもあった。
Robinsonは、個別のレポートに対し、予定外のメンテナー作業が2時間から8時間必要になることがあると述べた。最終的に脆弱性が存在しないという結論になった場合でも、そのコストは発生する。
問題は偽陽性だけではない。自動化システムは、重複した発見を送ったり、文書化された挙動を誤読したり、脅威モデルを無視したり、影響の小さい欠陥を過大評価したりする可能性がある。
幻覚による脆弱性は、レポートが内部的に整合して聞こえるため、特にコストが高い。審査担当者は、参照された関数、制御パス、または悪用条件が創作されたものだと判明するまで、詳細な技術的主張を追うことになり得る。
AIセキュリティ企業RunSybilの共同創業者であるVlad Ionescuは、以前のAIスロップ調査でこの体験を説明した。同氏によれば、レポートは技術的に妥当に見えても、審査担当者が調査すると、モデルが詳細を捏造していたことが分かる場合がある。
これは検証のボトルネックを生む。AIは発見候補の供給を増やすが、信頼できる審査担当者の数を自動的に増やすわけではない。
バグ報奨金には、不確かな主張を提出する金銭的な動機もある。研究者は多数の推測的なレポートを送ることができる一方、メンテナーが検証コストの大半を負担する。
評判システムやレート制限は悪用を減らせるが、それ自体にトレードオフがある。厳格なゲートは、プラットフォーム上の実績はないものの正当な発見を持つ新規研究者を排除する可能性がある。
本人確認の要件は、法的、職業的、または地理的なリスクに直面する人々による責任ある開示を妨げるおそれがある。提出手数料は、さらに大きな障壁となるだろう。
自動スクリーニングにも別の問題がある。機械生成のように聞こえることを理由にレポートを拒否するフィルターは、AI支援で発見または文書化された本物の脆弱性を捨ててしまう可能性がある。
本質的な区別は、AIがレポートに関与したかどうかではない。提出者が挙動を検証し、再現可能な証拠で主張を裏付けられるかどうかである。
エージェントが説得力のある文書を大規模に作成できるようになると、この基準を適用することはより難しくなる。文章の質は、もはや調査の質を示す信頼できるシグナルではない。
実務的な対応には、より強い証拠要件が含まれる可能性が高い。プログラムは、人間のレビューを割り当てる前に、最小限の再現例、影響を受けるバージョンの詳細、悪用のトレース、テストケース、または動作するパッチを要求できる。
こうした要件は、検証コストの一部を提出者へ戻す。また、コードを理解し、質問への回答に対応し続けられる研究者に有利に働く。
GoogleのAIバグレポート問題は、AIセキュリティの成功でもある
低品質な投稿を生み出している同じ技術が、人間の研究者が見逃した実在の脆弱性も発見している。
AI支援レポートをすべて無価値なものとして扱うなら、証拠を読み違えることになる。高度なモデルは、管理された条件下で意味のあるコード分析能力を実証している。
Anthropicは、Claude Opus 4.6が社内テストにおいて、オープンソースプロジェクト全体でこれまで知られていなかった脆弱性を500件以上発見したと述べた。同社によれば、開示前に人間または外部のセキュリティ研究者が各発見を検証したという。
Mozillaは、その取り組みから2週間で112件のレポートを受け取った。残る多数の発見を非セキュリティ上のバグに分類する一方で、高深刻度の欠陥14件を含む22件のセキュリティアドバイザリを発行した。
これらの結果は、大量の自動投稿とは異なるプロセスを示している。Anthropicは、機械による発見に人間による検証、協調的開示、そしてメンテナーとの焦点を絞ったコミュニケーションを組み合わせた。
ある事例では、モデルが疑われた欠陥が実在することを示すため、概念実証を作成したと報じられている。この段階によって、推測的なパターンが、審査担当者が検証できる証拠へと変わる。
Firefoxでの発見は、AI調査を全面的に禁止することが逆効果である理由も示している。モデルは、成熟し、広くテストされたコードを調べても、重大な欠陥を見つけ出せる。
したがって対立は、人間対AIではない。検証済みの調査対、説明責任を伴わないレポート生成である。
高品質なAI支援ワークフローには、人間の責任者が残る。その人物が出力を確認し、偽陽性を取り除き、影響を理解し、メンテナーとのコミュニケーションに責任を持つ。
低品質なワークフローでは、開示の終点を別の自動化先として扱う。エージェントがパターンを特定し、深刻度の説明を下書きし、独立した再現を行わずに提出する。
どちらのワークフローも洗練された文章を生み出せる。しかし、受信者の負担を減らすのは一方だけだ。
この違いは、Googleの一時停止がAIによるバグハンティングの失敗を証明するものではない理由を説明する。それは、Googleの提出アーキテクチャが、価値ある発見、重複、幻覚が混在する現状を吸収できなかったことを示している。
AI支援セキュリティは、最終的にはこのアーキテクチャの両側を改善し得る。プログラムはモデルを使い、重複をクラスタリングし、主張を既知の問題と比較し、悪用パスをテストし、不足する証拠を特定できる。
HackerOneなどのプラットフォームは、AIベースのトリアージ支援を導入し始めている。こうしたツールはレポートの優先順位付けに役立つが、その性能は誤拒否率と脆弱性見逃し率に照らして測定されなければならない。
自動化された審査担当者も幻覚を起こし得る。プログラムが研究者とメンテナーの間にモデルを置くなら、フィルターが確信を持って分類できない発見のためのエスカレーション経路が必要になる。
最も強力なモデルは、おそらく階層型のものだ。機械が低コストのチェックを行い、経験豊富なトリアージ担当者が生き残ったレポートを確認し、プロジェクトメンテナーは信頼できる発見のみを扱う。
このアプローチは、ソフトウェア貢献における継続的インテグレーションに似ている。メンテナーが詳細なレビューに時間を費やす前に、テストが明白な失敗をはじく。
セキュリティ上の主張は、通常のコード変更よりもテストが難しいままである。悪用可能性は、文脈、構成、信頼境界、そして自動チェックが誤解し得る攻撃者の能力に左右される。
それでも、機械で検証可能な証拠を求めることは、基準線を改善し得る。失敗するテスト、実行トレース、または再現可能なクラッシュを含むレポートは、審査担当者に具体的な評価対象を与える。
組織には、この作業を支える永続的な記録も必要です。検索可能なエンジニアリング・ナレッジベースは、チームが新たな発見を過去の報告、意思決定、修正内容と比較するのに役立ちます。
目的は、正当な発見を遅らせることではありません。無制限の生成によって、限られた人間のレビュー予算が消費されるのを防ぐことです。
CurlとLinuxが示す業界全体の問題
Googleの一時停止は、AIによって既存の信頼システムが圧迫された後、オープンソース・プロジェクトが開示チャネルを絞り込むという流れに続くものです。
最も明確な先例はCurlです。広く利用されているデータ転送プロジェクトは、2019年から運営してきた金銭的なバグ報奨金制度を2026年1月31日に終了しました。
メンテナーのDaniel Stenberg氏によると、この制度では87件の脆弱性が確認されました。しかし、報告の品質傾向は2025年に急速に悪化しました。
Curlでは以前、提出された報告の15%以上が脆弱性として確認されていました。この割合は2025年に5%未満まで低下し、20件に1件未満しか有効でなかったことを意味します。
Stenberg氏は、AIスロップ、その他の提出物における品質低下、プロジェクト改善よりも報酬を重視する報告者という、相互に関連する3つの傾向を原因として挙げました。
「終わりのないスロップ報告を管理することは、精神的に大きな負担となる」と、同氏はcurlの決定を発表した際に記しています。
Curlはセキュリティ開示の受け付けを停止したわけではありません。金銭的報酬を廃止し、推奨チャネルとしてHackerOneを残したうえで、研究者にはGitHubの非公開報告またはメールを案内しました。
この対応は、技術そのものではなくインセンティブを対象としたものでした。Stenberg氏は、報酬は正当な発見を呼び込む一方で、推測的な報告の提出も容易にしたと述べました。
同氏はこのトレードオフも認めています。支払いをなくせばノイズは減る可能性がありますが、困難な調査に多くの時間を割く熟練した独立研究者の動機を弱めるおそれもあります。
Linuxカーネル・コミュニティは、重複した発見に関する問題に直面しました。複数の研究者が同じコードに対して類似のAIツールを実行し、同一の問題を非公開チャネル経由で提出していました。
非公開開示では、他者がすでに発見を報告または議論していたことを研究者が確認できませんでした。メンテナーは重複報告を何度も差し戻し、すでに公開されている修正へ誘導しました。
Linus Torvalds氏は、この非公開セキュリティリストを「ほぼ完全に管理不能」と表現しました。同氏は、AIが検出した問題は、真に秘密性が必要な場合を除き、原則として公開プロジェクトのチャネルで扱うべきだと主張しています。
Linuxのドキュメントも、提出者に求める基準を引き上げました。研究者は簡潔な証拠を提示し、関連するメンテナーに連絡し、可能であればパッチを提供すべきです。
この方針は、人間の説明責任を維持します。AIは発見を支援できますが、報告内容を理解し、その結果に責任を負うのは人間でなければなりません。
Google、curl、Linuxは、それぞれのプログラム構造が異なるため、異なる介入策を選びました。Googleは提出カテゴリーを一時停止し、Curlは報酬を廃止し、Linuxは多くの報告を別チャネルへ誘導するとともに公開処理を重視しました。
共通する結論は、個別の方針の詳細より重要です。自動化エージェントがほぼ無制限に主張を生成できる状況では、意味のある提出コストを伴わない公開受付は機能しません。
最も大きなリスクにさらされるのは小規模プロジェクトです。Googleはエンジニアを割り当ててインフラを再設計できますが、ボランティアのメンテナーには専任のトリアージチームがない場合があります。
オープンソースソフトウェアは、商用製品、クラウドサービス、開発ツール、重要システムに広く組み込まれています。それでも、セキュリティ報告を精査する責任は、無償の貢献者数人に委ねられることがあります。
AIはこの不均衡を増幅させます。外部の人々が重要なコードを継続的にスキャンできるようにする一方で、考えられるすべての発見を検証、修正、調整するために必要な労力は提供しないからです。
その結果は、提出者に善意があったとしても、サービス拒否問題に似ています。各報告はメンテナーの注意を要求し、その総量が本物の脆弱性を押しのけかねません。
厳格なゲートは実際の脆弱性も隠しうる
プログラムは、低品質な報告量を減らしつつ、既存の研究者だけが利用できるセキュリティシステムを作らないようにしなければなりません。
Googleの一時停止は短期的にはレビュー担当者を保護しますが、正当な発見の報告経路も1つ失われます。10月1日以降に見つかった有効な製品脆弱性は、別の対象プログラムまたは開示チャネルを必要とする可能性があります。
この摩擦は重要です。研究者が企業の組織的な境界を常に理解しているとは限りません。オープンソースリポジトリの欠陥が、クラウド製品、依存関係、または下流のアプリケーションに影響することもあります。
複雑な振り分けルールは、開示の遅延や誤送信のリスクを高めます。また、受け付けられる非公開チャネルを研究者が特定できない場合、公開を促してしまうこともあります。
評判に基づくアクセスには別のリスクもあります。経験豊富な研究者は信頼しやすい一方で、新規参加者も歴史的に報奨金プログラムへ重要な発見をもたらしてきました。
既存のアイデンティティを優遇するシステムは、既存のアクセス格差を再生産しかねません。独立研究者、学生、大規模なセキュリティコミュニティの外にいる人々に不利となる可能性があります。
厳格な概念実証要件も危険になりえます。悪用可能性の実証には、実データの取り扱い、保護策の回避、あるいはプログラム規則に違反するテストが必要になることがあります。
したがって、プログラムには強固でありながら安全な証拠基準が必要です。最小限の再現例、制御されたテスト、詳細なコードパスによって、有害な悪用を必要とせずに信頼性を示せます。
AI生成の文章を確実に検出する手段もありません。基礎となる作業が正当なものであっても、研究者は翻訳、編集、コード説明、整形にモデルを日常的に利用しています。
文体に基づいて報告を却下すれば、慎重な開示を罰し、AI利用を隠すインセンティブを生むことになります。それでは、報告された欠陥が実在するかどうかを判断できません。
Googleの公開声明には、いくつか未回答の疑問が残っています。同社は、どのスクリーニング措置が失敗したのか、急増の中でどれだけの正当な発見があったのか、どのような再設計を検討しているのかを明らかにしていません。
また、一時停止が、より多くの自動化、より高い証拠基準、アクセス制限、または別の報酬モデルで終わるのかも不明です。
数値がないため、外部からの評価には限界があります。「圧倒的大多数」という表現は深刻さを伝えますが、有効性が既存のしきい値をわずかに下回っただけなのか、ほぼ完全に崩壊したのかは明らかになりません。
読者は、Googleの経験を普遍的なものと見なすことも避けるべきです。Mozillaは以前、業界全体で懸念が広がるなかでも、ある期間に無効報告の却下率は安定していたと述べています。
プログラム設計、プロジェクトの可視性、報酬インセンティブ、提出ルールはいずれも、報告の量と品質に影響します。あるプロジェクトで機能する方針が、別のプロジェクトでは失敗する可能性があります。
AIシステム自体も急速に変化しています。より優れたモデルは、より説得力のある誤検知を生み出しうる一方、より強い証明を生成し、ハルシネーションを減らすこともできます。
この二重の動きにより、固定的なルールは脆弱になります。プログラムには、どのツールが使われたかを推測するのではなく、証拠を評価する測定可能な品質管理が必要です。
セキュリティ責任者にとって中心的な指標は、生の報告件数ではありません。有用な指標には、確認済み脆弱性率、重複率、トリアージ時間の中央値、修正時間、レビュー担当者の負荷が含まれます。
プログラムは、報告数が増えても有効性が低下することがあります。逆に、受付を厳格化すれば件数を減らしながら、重大な発見がメンテナーに届く割合を高められる可能性があります。
したがって、Google OSS VRPの一時停止は、その代わりに何が導入されるかで評価されるべきです。圧倒されたキューを閉じることは理解できますが、持続的なセキュリティ成果には、有効な報告のための信頼できる経路が必要です。
Googleのオープンソース・バグ報奨金は次にどうなるのか
Googleの一時停止が、より良い開示システムとなるのか、それとも公開参加からの恒久的な後退となるのかは、3つの兆候で見極められます。
最初の兆候は、2027年第1四半期中に予定されているGoogleの更新です。最も重要な詳細は、対象資格、証拠基準、自動スクリーニング、異議申し立て手続きに関するものとなるでしょう。
明確な再現要件を伴う再開であれば、Googleがこの一時停止を受付の再設計に活用したという見方を強めます。無期限の延長であれば、公開提出が経済的に依然として困難であることを示唆します。
Googleが、実行可能なテスト、影響を受けるコミット、悪用のトレース、または提案する修正を報告者に求めるかに注目すべきです。こうしたルールは、AI支援を禁止せずに、研究者側へ責任を移すことになります。
2つ目の兆候は、再開後の確認済み報告率です。Googleは現在のベースラインを公表していないため、今後の有効率と重複率に関する透明性があれば、新システムの評価に役立つでしょう。
開示へのアクセスを安定的に維持しながら確認率が上がれば、より厳格なフィルタリングを支持する材料となります。参加者が急減すれば、ゲートがスパムだけでなく正当な研究者も排除している可能性があります。
トリアージ時間も重要です。レビュー担当者が信頼できる報告をより迅速に評価できるようになれば、Googleは再設計が単に目に見える件数を減らしたのではなく、隠れた労力を減らした証拠を得られます。
3つ目の兆候は、他のプロジェクトやプラットフォームがどのように対応するかです。Curlは報酬を廃止し、Linuxは自動化された発見を別チャネルへ誘導し、Googleは1つの提出カテゴリーを一時停止しました。
より多くのプログラムが検証済みの再現、パッチ要件、または評判のしきい値を採用すれば、こうした慣行はAI支援型開示の標準になる可能性があります。
プラットフォームは共有の防御策を構築することもできます。プログラム横断の重複検出、標準化された機械可読な証拠、説明責任を持つエージェントIDは、重複作業を減らせる可能性があります。
最も建設的な結果は、発見の規模と提出の規模を分離することです。研究者はエージェントを広範に実行できますが、人間のレビューキューに入るのは、検証済みかつ重複排除された発見だけとなります。
そのモデルには、すべての引き渡し段階で責任が必要です。ツール開発者は検証を前提に設計し、研究者は発見をテストし、プラットフォームは慎重にフィルタリングし、メンテナーには明確なエスカレーション経路が必要です。
AIセキュリティツールを使う開発者は、すでにこうしたルールが存在するかのように行動すべきです。すべての主張を再現し、影響を受けるコードを理解し、公開されているIssue履歴を確認し、現実的な影響を文書化する必要があります。
また、提出後も対応可能な状態でいるべきです。基本的な技術的質問に答えられない報告者は、調査コスト全体をプロジェクトへ転嫁することになります。
企業にとって、この教訓はバグ報奨金にとどまりません。AIによってコンテンツ生成が安価になり、評価が高コストなままであれば、あらゆる公開受付システムが過負荷になる可能性があります。
サポートキュー、求人応募、助成金プログラム、プルリクエスト、コンプライアンス報告は、いずれも同じ基本的な不均衡に直面します。希少な資源は、もはや文章作成ではありません。信頼できるレビューです。
Googleのオープンソース・バグ報奨金の一時停止は、この不均衡を高リスクな場面で可視化しました。誤ったセキュリティ報告は時間を浪費し、見逃された本物の脆弱性は数百万の下流ユーザーを危険にさらしかねません。
課題は、AIと人間の研究者のどちらかを選ぶことではありません。自動化が裏付けのない主張を増幅させるのではなく、検証済みのセキュリティ作業を増やす開示システムを設計することです。
Googleには、次回の更新までにそのシステムの姿を示す時間があります。より強力な証拠ゲートと意味のあるアクセスを備えて再開するのか、それとも報告件数の増加に伴い公開参加は狭まり続けるのでしょうか。
