「AIを使った未検証の報告は単なるノイズ」 GitHubがバグ報奨金制度を厳格化：AI時代にセキュリティ担当者が直面する新たな課題

GitHubは同社のブログで「バグ報奨金プログラム」について基準を見直す方針を発表した。GitHubは「AIを活用して問題を発見する人が増えることはポジティブな進展だ」と評価する一方、「正当ではない報告も著しく増加しており、業界全体の課題だ」と指摘している。

[石川俊明，＠IT]

　GitHubは2026年5月15日（米国時間）、同社の「バグ報奨金プログラム」について、報告品質に関する基準を見直す方針を発表した。背景にあるのが、AIを含む新しいセキュリティツールの普及に伴い、脆弱（ぜいじゃく）性報告の量が増える中、セキュリティ上の影響やPoC（概念実証）を示さない報告も増えているという問題だ。

　GitHubは「研究者がAIツールを使用することには何の問題もない。セキュリティ研究においてAIが果たす役割は今後ますます大きくなると予想される。AIの活用は大歓迎だ」とした上で、「PoCがない報告、精査に耐えない理論上の攻撃シナリオ、既に対象外と明示されている項目の報告も増えている。これは業界全体のバグ報奨金プログラムが直面している課題であり、人間の研究者が、報告内容の正確性に責任を持つ必要がある。ツールの問題ではなく、作業の質の問題だ」との見方を示している。

生成AIを活用した未検証の報告は「単なるノイズ」

　GitHubは今後、報告をより厳格に評価するとしており、「完全な報告」の基準を引き上げる。具体的には以下の3点が求められる。

• セキュリティへの影響を実証する動作可能なPoC：「〜につながる可能性がある」という理論や説明だけでなく、攻撃者が何を達成できるのか、悪用と具体的な影響を証明する動作可能なPoCを提出する必要がある
• スコープと対象外項目への理解：プログラムの対象外となるカテゴリーに関する報告は「適用外」としてクローズされる。報告者側の評価に悪影響を及ぼす可能性があるため、事前の確認を求めている
• 提出前の人間による検証： スキャナーやAIアシスタントなど、どのようなツールを使用した場合でも、提出前に人間による手動の検証と再現が不可欠となる。検証されていない出力結果は「単なるノイズ」と見なされる

　「ユーザーが悪意あるリポジトリを自らクローンする」「信頼できないコードを実行する」「攻撃者が用意したコンテンツをAIツールに読み込ませる」といった内容に関連する報告についてGitHubは、「プラットフォーム側の責任ではなく、GitHubを利用するユーザー側の責任（そのコンテンツを信頼するかどうか）だ」と説明している。

　なお、コードやドキュメントの修正につながるものの低リスクな報告に対しては、金銭的な報奨ではなく、GitHubのノベルティグッズを報奨する方針も明らかにしている。

「報告件数よりも1件当たりの質の方が重要」

　GitHubは、報告の書き方について次のようにポイントをまとめた。「優れた報告は簡潔かつ構造化されており、以下の3つの要素のみで構成されるべきだ」と指摘している。

1. 問題の短い概要
2. 裏付けとなる証拠（スクリーンショットや端末の出力など）を伴う明確な再現手順
3. 攻撃者が達成できることを説明する、影響についての記載

　「複数ページにわたる理論上のシナリオや、背景事情の繰り返し、AIが生成した不要な長文といった冗長な報告は、重要な報告を埋もれさせ、運営側のトリアージ（優先順位付け）を遅らせる原因になる」（GitHub）

　GitHubはセキュリティ研究者に対し、「これまで報告件数を優先してきたのであれば、深さを追求する方向へシフトしてほしい」と呼び掛けている。十分に調査・検証された1件の発見は、推測に基づく10件の発見よりも、報奨金の支払いやレピュテーションの面ではるかに価値があると結論付けている。

記者の目：生成AIの進化がもたらす「ノイズ」にどう立ち向かうか

　多くの企業にとって、脆弱性報告者に報奨金を支払う制度は身近ではないだろう。だが、一般企業においても問い合わせフォームやカスタマーサポート、営業窓口に加え、取引先、委託先、監査会社、外部機関を経由して、セキュリティに関する指摘が届くことはあり得る。

　GitHubの事例のように、受け取る側から見て、本当に価値ある報告と、未検証の「それらしい報告」の区別が難しくなり、「ノイズ」が増えれば、重大な警告まで見落としてしまうリスクが高まる。そうした警告を見落とし、攻撃者に脆弱性を悪用されれば、自社ブランドやサービスへの深刻なレピュテーションリスクに直結する。

　こうした状況下では、単に脆弱性報告の窓口を用意するだけでは不十分だ。届いた内容を技術的に確認して「ノイズ」を弾き、自社への影響範囲を見積もり、必要に応じて開発部門や顧客対応部門へ迅速につなぐトリアージの役割が不可欠になる。

　その役割を担う組織としてあらためて想起されるのが、社内の情報システムを守る「CSIRT（Computer Security Incident Response Team）」や、自社製品・サービスの脆弱性対応を担う「PSIRT（Product Security Incident Response Team）」だ。

　AIの普及に伴い、脆弱性を発見し悪用されるまでのスピードが劇的に変わりつつある。そうした中で自社の重大なセキュリティリスクを見落とさずに拾い上げ、適切に対処できる体制を確立できるかどうか。AI時代において企業のインシデント対応力強化もよりいっそう問われることになりそうだ。