はじめに
GitHubは2026年5月15日、バグバウンティプログラムの新方針を公式ブログで発表しました。AIツールの普及が参入障壁を下げ申請件数が急増する一方、実証を欠く低品質レポートも増加しています。本稿では、GitHubが打ち出した提出基準の厳格化・共有責任の明確化・報酬体系の見直しという3つの変更点を解説します。
参考記事
- タイトル: Raising the bar: Quality, shared responsibility, and the future of GitHub’s bug bounty program
- 著者: Jarom Brown
- 発行元: GitHub Blog
- 発行日: 2026年5月15日
- URL: https://github.blog/security/raising-the-bar-quality-shared-responsibility-and-the-future-of-githubs-bug-bounty-program/
関連記事
要点
- GitHubのバグバウンティプログラムは、AI普及による申請量増加と低品質レポートの急増を受け、提出基準を厳格化した
- 有効な申請には動作するPoC（Proof of Concept：概念実証コード）と具体的なセキュリティ影響の実証が必須となった
- AI支援ツールの活用は歓迎されるが、提出前の人による検証が研究者の責任として明確に求められる
- GitHubは「共有責任モデル」を明確化し、ユーザーが自ら選択したコンテンツに起因するリスクはGitHub側のセキュリティ管理境界外であると示した
- 重大なセキュリティ影響がなく修正に至った案件は、バウンティ報酬からグッズ（スワッグ）での謝礼に切り替わる
詳細解説
申請量増加とプログラム改革の背景
GitHubによれば、バグバウンティへの申請量はここ1年で業界全体として大幅に増加しています。AIツールがセキュリティ研究の参入障壁を下げたことが主な要因であり、それ自体は多くの攻撃面を探索する機会が増えるというポジティブな側面もあります。しかし同時に、実証のない理論的な攻撃シナリオや、GitHubが既に公開している対象外リストに含まれる報告が急増しています。この問題は業界全体に共通しており、プログラムを完全に廃止した事例も他社で相次いでいます。GitHubはその方向には進まず、プログラムの品質向上に投資することを選択しました。
新しい提出基準：求められる「実証」
今後、GitHubは以下の3点を申請評価の基準として厳格に適用します。
- 動作するPoCと影響の実証：攻撃者が実際に達成できることを示す必要があります。「〜につながる可能性がある」という記述だけでは不完全とされ、実際にセキュリティ上の境界を越えられることを実演するPoCが求められます。
- スコープと対象外リストの事前確認：DMARC/SPF/DKIM設定、ユーザー列挙、攻撃経路の実証のない不在セキュリティヘッダーなどは対象外として明示されています。これらを含む申請はHackerOne上のシグナルや評判にも影響する可能性があります。
- ツール出力の手動検証：スキャナー、静的解析、AIアシスタントを問わず、いかなるツールの出力も提出前に研究者自身による検証・再現確認が必要です。
また、レポートの形式についてもGitHubは指針を示しています。理想的なレポートは、①問題の短い要約、②再現手順と根拠（スクリーンショット・HTTPリクエスト・ターミナル出力など）、③攻撃者が実際に達成できることの説明、の3点に絞ることが推奨されます。長大な理論的ナラティブやAI生成の冗長な文章はトリアージを遅延させるとして、明確に注意が促されています。
AI活用は歓迎——求められるのは検証
GitHubはAIツールの活用を明示的に歓迎しています。GitHubはすでに自社の内部セキュリティプログラムにAIを活用しており、優れた外部研究者も同様に活用していると認識しています。AI支援で発見し、人間が検証・再現確認し、有効なPoCとともに提出した申請は質の高い申請とみなされます。一方、検証なしにツール出力をそのまま提出した場合は「ノイズ」として扱われます。GitHubは「ツールは問わない、求められるのは作業の質だ」と明言しています。
この基準はスキャナーや静的解析ツールに対してこれまで設けてきた考え方と同じです。GitHub Security LabがAIを活用した脆弱性スキャンを公開したように、AI×セキュリティの組み合わせはGitHub自身も積極的に推進しており、外部研究者との協力関係を深めたい意図が今回の方針変更にも表れていると思います。
共有責任モデルの明確化
GitHubが別途説明しているのが「共有責任モデル」です。報告として多く寄せられるのは、ユーザーが攻撃者の制御するコンテンツを自ら操作した結果として問題が発生するシナリオです。GitHubはこのような場合、セキュリティの境界はユーザーの選択にあると位置付けています。
GitHubが具体例として挙げているのは次のようなパターンです。AIツールに信頼していないコンテンツを入力した結果のプロンプトインジェクション、ユーザーがチェックアウトしたリポジトリのGitフックによるコード実行、クローン先リポジトリ内の悪意あるコンテンツ、信頼されていない入力を処理したLLMが予期せぬ出力を返すケースなどです。これらはいずれも「ユーザー自身がそのコンテンツを信頼することを選択した」という共通点を持ちます。
一方で、ユーザーが悪意あるコンテンツを積極的に信頼する行為を必要とせずに、GitHubのセキュリティ管理を実際に回避できる発見は、最も価値の高い申請としてGitHubが歓迎するものです。共有責任の領域にある研究であっても、防御の盲点となりうる発見は積極的に報告してほしいというスタンスです。
低リスク案件の報酬見直し
重大なセキュリティ影響を持たないものの、コードやドキュメントの修正につながった申請については、バウンティ報酬ではなくGitHubのグッズでの謝礼に切り替わります。GitHubによれば、この変更の目的は「貢献を認めつつ、バウンティのリソースをプラットフォームセキュリティに最も高いインパクトをもたらす発見に集中させること」です。研究者には、量的な最適化よりも深い高インパクト研究に時間を投資することを促しています。
まとめ
GitHubは今回の基準更新で、AI時代のバグバウンティ運営における一貫した姿勢を示しました。AI支援ツールは歓迎しつつも、人による検証を研究者の責任として求めるという原則は、ツールの進化に関わらず変わらないものと言えます。AIと外部研究者の連携がセキュリティ向上の軸になりつつある動向に関心がある方は、OpenAIが2026年3月に開始したSafety Bug Bountyプログラムもあわせてご覧いただければと思います。
