2025.02.25 プラットフォーム

GitHubバグバウンティ（バグ報奨金プログラム）の仕組み・報奨金額・参加方法

GitHubバグバウンティは、セキュリティ研究者がGitHubの製品やサービスに潜む脆弱性を見つけて報告し、その深刻度に応じた報奨金を受け取る制度です。2014年に開始され、報告の受付・審査・支払いはHackerOne上のプログラム（hackerone.com/github）で運用されています。GitHubはこれまでに研究者へ累計400万ドル超を支払っており（2023年末時点、GitHub／HackerOne公式ブログの10周年記事）、外部の視点で不具合を早期に潰すための中核施策になっています。この記事では、報奨金額の目安・対象スコープ・報告手順・参加の始め方を一次情報で整理します。

まとめ：GitHubバグバウンティの要点

  • 運用基盤：HackerOneのプログラム（hackerone.com/github）。2014年開始、2016年にメール受付からHackerOneへ移行。
  • 報奨金の目安：重大度で段階化。Criticalは20,000〜30,000ドル超、Lowでも617ドルから（公式ガイドライン。最新額はbounty.github.comで要確認）。
  • 対象：github.com配下・npmjs.com・npmjs.org・GitHub Enterprise Server/Cloud・Mobile・CLI・Desktop・Actionsなど、GitHubが自ら運営する範囲。
  • 対象外・禁止：DoS、フィッシング／ソーシャルエンジニアリング、他ユーザーや第三者リポジトリへの実害、重複報告。
  • 混同注意：GitHub「製品」の脆弱性を扱うバグバウンティと、OSSの脆弱性・CVEを扱うGitHub Security Labは別枠。

GitHubバグバウンティの仕組みと運用の全体像

制度の対象は「GitHubが自ら運営する製品・サービス」に限られます。研究者がスコープ内で脆弱性を見つけ、HackerOne経由でレポートを提出すると、GitHubのセキュリティチームが再現性と影響度を審査し、認定されれば報奨金が支払われ、並行して修正が進みます。金銭だけの制度ではなく、内部チームだけでは拾いきれない攻撃者視点の指摘を外部から取り込むための仕組みです。

運用の歴史は明確です。2014年にメールベースで開始し、初年度の支払総額はおよそ5万ドルでした。2016年にHackerOneへ移行し、以降は同プラットフォーム上でトリアージ・支払い・公開レポート管理を行っています。2018年には後述する法的セーフハーバーを導入し、誠実な研究を法的リスクなく行える範囲を明文化しました。

報奨金額の目安（重大度別レンジと支払い実績）

報奨金は脆弱性の重大度で段階化されています。GitHubが公開しているガイドラインの目安は次のとおりです。金額はプログラム更新で変わるため、応募前に必ず公式（bounty.github.com）で最新値を確認してください。

重大度 報奨金の目安（USD） 該当する脆弱性の例
Critical 20,000〜30,000＋ リモートコード実行、認証の全面回避
High 10,000〜20,000 権限昇格、広範なデータ露出
Medium 4,000〜10,000 限定的な認可欠陥、機能悪用
Low 617〜2,000 影響の限定的なXSSや情報漏えい

Criticalの上限3万ドルはあくまで目安で、例外的に高く評価された報告には上乗せがあります。実績面では、2023年に単発で75,000ドルという過去最高額の支払いが記録され、同年に累計支払いが400万ドルを超えました。低リスクでも617ドルから支払われるため、小さな指摘を積み重ねて実績を作る使い方も成り立ちます。

対象範囲（スコープ）と対象外・禁止事項

報奨金の対象になるGitHubのサービス

対象はGitHubが直接運営する範囲です。主なスコープには次が含まれます。

  • github.com とそのサブドメイン（一部の除外あり）、GitHub API・GraphQL API
  • githubusercontent.com、githubassets.com などの関連ドメイン
  • npmjs.com / npmjs.org（npmレジストリとWeb）
  • GitHub Enterprise Server と Enterprise Cloud、GitHub Actions
  • GitHub Mobile（iOS／Android）、GitHub CLI、GitHub Desktop

スコープと除外対象は更新されるため、報告前にbounty.github.com/scopeで対象可否を確認するのが前提です。除外側の例としては、shop.github.com・blog.github.com・community.github.com などGitHub本体の脆弱性と直結しないサブドメインが挙げられています。

対象外・無効になる報告と禁止行為

次のような報告は無効、または報奨対象外になりやすい点に注意してください。

  • UIの軽微な表示崩れ、セキュリティツールの誤検知アラート
  • すでに報告済みの脆弱性の再報告（公開レポートで重複を確認する）
  • GitHubが管理していない外部サービスや第三者リポジトリの設定不備

さらに、以下は禁止行為であり、報奨の対象外になるだけでなく法的措置の対象になり得ます。調査の過程で一般ユーザーや実データに被害を及ぼさないことが絶対条件です。

  • サービスへのDoS／DDoS攻撃、過負荷を伴う自動スキャン
  • フィッシングやソーシャルエンジニアリング、物理的侵入
  • 他人のアカウント・第三者リポジトリへの無許可アクセスやデータ持ち出し

脆弱性報告の流れ（HackerOneでの提出手順）

報告はHackerOneのGitHubプログラムから提出します。評価は「再現できるか」「影響がどこまで及ぶか」「説明が明確か」で決まるため、レポートの質がそのまま報奨額に効きます。おおまかな流れは次のとおりです。

  1. スコープと公開レポートを確認し、対象内かつ重複でないかを事前チェックする。
  2. HackerOne上でレポートを作成する。概要・影響範囲・再現手順（環境やバージョンを明記）・攻撃シナリオ・可能なら修正案を含める。
  3. GitHubのセキュリティチームがトリアージし、再現と影響度を検証する。
  4. 重大度に応じて報奨額が決まり、支払いと修正が進む。審査から支払いまでは数週間から数か月かかることがある。

再現手順が曖昧なレポートは影響度を過小評価されやすく、報奨対象から外れる原因になります。スクリーンショットや最小限の再現コードを添え、「どのように悪用され得るか」まで書き切ることが評価を左右します。

バグバウンティとGitHub Security Labの違い（混同しやすい点）

「GitHubで脆弱性を報告する」と一括りにされがちですが、窓口は目的で分かれます。ここを取り違えると報告先を誤り、報奨の対象にもなりません。

  • GitHubバグバウンティ：GitHub自社の製品・サービス（github.com本体、Actions、Enterprise等）の脆弱性が対象。HackerOneで報告し、報奨金が支払われる。
  • GitHub Security Lab／Advisory Database：GitHub上でホストされるオープンソースソフトウェアの脆弱性を対象とし、CVEの採番や開発者への調整（コーディネート）を担う枠組み。自社バウンティとは支払い体系も窓口も別。

自組織のリポジトリを守る文脈では、報告を待つバウンティとは別に、GitHubが提供する検知系の機能も押さえておくと役割分担が整理できます。コードの脆弱パターンを自動検出するGitHub Code Scanning（CodeQL）の仕組みと設定方法や、それらをまとめたGitHub Advanced Securityの料金と機能は、外部研究者の報告を待つ前に自社で脆弱性を潰すための手段です。

初心者がバグバウンティを始める手順

未経験からでも参加できますが、いきなりCriticalを狙うより、影響の小さい報告で「通るレポート」の型を身につけるのが近道です。次の順で準備すると無駄打ちを減らせます。

  1. HackerOneでアカウントを作り、GitHubプログラムのスコープとルールを読み込む。
  2. 過去の公開レポートを読み、どんな指摘がどう評価されたか（受理・却下の判断基準）を把握する。
  3. Webセキュリティの基礎（認証・認可、XSS、SSRFなど）とGitHub APIの挙動を理解する。
  4. 小さく確実な脆弱性を、再現手順つきの明確なレポートで提出し、実績を積む。

脆弱性の傾向を体系的に学ぶには、実在のCVE事例を追うのが有効です。たとえばCVE-2026-31431「Copy Fail」の影響範囲と対処や7-Zipの主要CVEと深刻度のように、実際の脆弱性が「どこに・どんな条件で」生じるかを分解して読むと、報告に必要な観点が身につきます。

他社プログラムとの違い（GitHubの立ち位置）

報奨金の上限だけを比べると、GitHubは大手クラウド勢より控えめです。GoogleのVRPは最大15万ドル超、MicrosoftのプログラムはHyper-VやAzure等の一部で最大25万ドル超に達する一方、GitHubの上限はCritical帯で3万ドル前後が目安です。ただしこれは対象範囲の違いによるもので、OS・クラウド基盤まで含む両社に対し、GitHubはソースコード管理・CI/CD・APIという開発基盤に的を絞っているためです。

裏を返せば、GitHub ActionsやAPI、リポジトリ権限まわりの知見がある研究者にとっては、専門性がそのまま報奨につながりやすい領域といえます。金額の絶対値で他社と比べるより、自分の得意分野が対象スコープと重なるかで選ぶのが実利的です。

よくある質問

GitHubのバグバウンティは初心者でも参加できますか？

参加自体に資格要件はなく、HackerOneのアカウントがあれば誰でも報告できます。ただし報奨は再現性と影響度で評価されるため、まずは影響の小さい脆弱性を明確なレポートで通し、実績を積むのが現実的です。

報奨金はいくらもらえますか？

重大度で段階化されており、Lowで617ドルから、Criticalで20,000〜30,000ドル超が目安です。2023年には単発75,000ドルの過去最高額も記録されています。金額は改定されるため最新はbounty.github.comで確認してください。

報奨金はどのように支払われますか？

HackerOne経由で支払われます。脆弱性が認定されると重大度に応じて金額が決まり、報告者が受け取り方法を選択して送金されます。審査から支払いまでは数週間から数か月かかることがあります。

どんな報告は対象外になりますか？

UIの軽微な不具合、誤検知アラート、重複報告、外部サービスや第三者リポジトリの問題は対象外になりやすい項目です。DoSやフィッシング、他ユーザーへの実害を伴う行為は禁止で、法的措置の対象にもなり得ます。

GitHub Security Labとバグバウンティは何が違いますか？

バグバウンティはGitHub自社製品の脆弱性を対象に報奨金を支払う制度です。GitHub Security LabはGitHub上のオープンソースの脆弱性を対象にCVE採番や開発者調整を担う別枠で、窓口も評価体系も異なります。

関連記事

資料請求

RELATED POSTS 関連記事

一覧へ戻る