バグバウンティプログラム2025: 費用、報奨金、始め方
CyberLord Team

バグバウンティプログラムは、外部の倫理的ハッカーに脆弱性を報告してもらい、確認済みの成果に対して報奨金を支払う仕組みです。大企業だけの制度と思われがちですが、公開Webアプリ、API、モバイルアプリを持つ企業なら、規模に応じて導入を検討する価値があります。
ただし、準備不足のまま公開すると、無効な報告が増え、社内チームが疲弊し、法務や顧客対応で混乱します。この記事では、2025年にバグバウンティを始める企業が、費用、報奨金、対象範囲、受付体制をどう設計すべきかを日本語で整理します。第三者のシステムを無断で試すことを勧める内容ではありません。
バグバウンティとは何か
バグバウンティは、企業が検証可能な脆弱性報告に対して報酬を支払う制度です。一般的な流れは次の通りです。
- 企業がテストしてよい対象を定義する
- 研究者が許可された範囲で脆弱性を探す
- 報告フォームやプラットフォームから証拠を提出する
- 企業またはトリアージ担当が影響度を確認する
- 深刻度に応じて報奨金を支払う
ポイントは、対象範囲とルールが明確であることです。「当社サイトを自由にテストしてください」という曖昧な案内は危険です。DoS、ソーシャルエンジニアリング、従業員への攻撃、第三者サービスへの攻撃など、禁止事項を必ず書く必要があります。
2025年の主要な選択肢
代表的な選択肢は、HackerOne、Bugcrowd、または自社運用です。HackerOneやBugcrowdのようなプラットフォームは、研究者コミュニティ、レポート管理、重複確認、トリアージ、支払い処理を支援します。初めての企業には、運用負荷を下げられる利点があります。
一方、自社運用は手数料を抑えられますが、スパム報告、再現性の低い報告、危険な検証、支払い交渉を社内で処理する必要があります。セキュリティチームが小さい企業ほど、いきなり自社運用で公開プログラムを始めるのは避けた方が安全です。
費用と報奨金の考え方
バグバウンティの費用は、プラットフォーム利用料、報奨金、社内工数、修正工数に分かれます。安く始めたい場合でも、報告を確認する人、開発チームへ修正を渡す人、研究者へ返信する人が必要です。
一般的な報奨金の考え方は次の通りです。
| 深刻度 | 目安 | 例 |
|---|---|---|
| Low | $100-$500 | 軽微な情報漏えい、低影響の設定ミス |
| Medium | $500-$2,500 | XSS、限定的な認可不備 |
| High | $2,500-$10,000 | 認証回避、重要データへのアクセス |
| Critical | $10,000以上 | RCE、広範囲な顧客データ漏えいにつながる欠陥 |
報奨金は高ければよいわけではありません。自社の資産価値、悪用時の被害、修正の緊急度、同業他社の水準を見て決めます。低すぎる報奨金は有力な研究者を遠ざけますが、高すぎる報奨金は審査基準が曖昧なままだと予算を圧迫します。
いきなり公開しない
初回はプライベートプログラムから始めるのが現実的です。信頼できる少数の研究者を招き、対象範囲、返信速度、重複処理、報奨金判断、修正フローを試します。3か月から6か月ほど運用してから、対象を広げるか公開化を判断します。
公開前に準備すべきものは次の通りです。
- テスト対象のURL、API、モバイルアプリ
- 明確な禁止事項
- 報告テンプレート
- 深刻度判定ルール
- 返信SLA
- 修正担当チーム
- 支払いと税務の処理
- 法務承認済みのセーフハーバー文言
セーフハーバーは、研究者がルール内で行った調査について、企業が不必要に法的措置を取らないことを示す考え方です。これが曖昧だと、優秀な研究者ほど参加を避けます。
ペネトレーションテストとの違い
バグバウンティは継続的で、成果報酬型です。一方、ペネトレーションテストは期間、範囲、手法、報告書が明確なプロジェクトです。コンプライアンス、経営報告、内部ネットワークの検証には、今でもペネトレーションテストが向いています。
実務では、年1回から2回の/ja/services/penetration-testingと、公開資産向けの限定的なバグバウンティを組み合わせると効果的です。ペンテストで基礎的な欠陥を減らしてからバグバウンティを始めると、研究者から届く報告の質も上がります。
よくある失敗
失敗しやすいのは、対象範囲が広すぎる、報奨金が低すぎる、返信が遅い、社内の修正権限が決まっていない、の4つです。研究者は報告後の扱いをよく見ています。数週間返事がない、重複の説明がない、再現手順を何度も求める、といった運用は評判を落とします。
また、報告を受けても修正できない状態で始めるのも危険です。バグバウンティは発見の仕組みであって、修正の仕組みではありません。修正スプリント、緊急パッチ、例外承認のルートを先に決めておく必要があります。
導入判断の目安
小規模企業で公開アプリが少ない場合は、まず脆弱性診断やペネトレーションテストから始める方が適しています。顧客データ、決済情報、管理者向けポータル、API連携がある企業は、プライベートなバグバウンティを検討できます。大規模なSaaSや金融、医療、ECでは、継続的な外部報告窓口を持つことがセキュリティ姿勢の一部になります。
Cyberlordでは、バグバウンティを始める前の対象範囲設計、診断、報告フロー作成、修正優先度付けを支援できます。制度化の前に自社の準備状況を確認したい場合は、/ja/contactから相談してください。
まとめ
バグバウンティプログラムは、うまく設計すれば外部の視点を継続的に取り入れられる強い仕組みです。しかし、対象範囲、報奨金、返信体制、法的ルールが曖昧なまま始めると、コストだけが増えます。2025年に始めるなら、まず小さく、プライベートに、修正できる体制を整えてから広げるのが安全です。