自分のラボとCTFで力をつけたら、いよいよ本物の対象に触れる番です。そして、それを完全に合法に行える唯一の入口が、バグバウンティです。
バグバウンティは、企業が「この範囲なら調べてよい、見つけたら報奨を払う」と公開する制度。ホワイトハッカーと法律で定めた**安全地帯③(許可されたスコープ)**そのものです。本記事は、報奨を得るための正規の歩き方を、公式(HackerOne/Bugcrowd/disclose.io)に忠実に解説します。
これはホワイトハッカーになるには【完全ロードマップ】の実戦・収益化パートを深掘りするスポークです。
1. バグバウンティと VDP の違い
まず用語を整理します。似て非なる2つがあります。
| 制度 | 目的 | 報奨 | 性格 |
|---|---|---|---|
| バグバウンティ(Bug Bounty) | 脆弱性を見つけてもらう | あり(深刻度に応じた金銭) | 競争的・収益化できる |
| VDP(脆弱性開示プログラム) | 報告を安全に受け付ける窓口 | 原則なし(謝辞・殿堂入り等) | 善意の報告の“受け皿” |
Bugcrowd の定義でも、VDPは「報告のための安全な経路を提供する」もの、バグバウンティは「報奨で研究者を動機づける」ものと区別されます。初心者はまずVDPや入門者向けプログラムで“報告の作法”を覚え、慣れたら報奨つきへ進むのが安全です。
2. プラットフォーム — どこで始めるか
個人がいきなり企業と直接やりとりするのは大変です。間に立つのがバグバウンティ・プラットフォームです。
- HackerOne — 最大手。多数の有名企業のプログラムが集まる。協調的脆弱性開示(CVD)の運用が整備されている(HackerOne CVD)。
- Bugcrowd — もう一つの大手。深刻度評価の業界標準 VRT(Vulnerability Rating Taxonomy) を公開している。
- Internet Bug Bounty — OSS/ソフトウェアサプライチェーンを対象にした共同プログラム。
プラットフォームは、スコープの提示・報告の受付・トリアージ・報奨の支払い・開示の調整までを仲介します。研究者は登録し、各プログラムのスコープとルールを読んでから動きます。
3. 最重要スキルは「スコープを正確に読む力」
意外に思うかもしれませんが、バグバウンティで最初に磨くべきは**攻撃力ではなく「スコープと safe harbor を正確に読む力」**です。ここを誤ると、報奨どころか違法行為になります。
各プログラムは、必ず次を明示します。
- In-Scope — テストしてよい資産(ドメイン、API、アプリ)。
*.example.comのようなワイルドカード指定もある。 - Out-of-Scope — テスト禁止の資産(第三者サービス、特定サブドメイン等)。
- 禁止される手法 — DoS/DDoS、ソーシャルエンジニアリング、物理侵入、他ユーザーの実データの持ち出しなどは、多くのプログラムで明確に禁止。
- safe harbor(セーフハーバー) — 「スコープとルールを守る善意の研究に対しては法的措置を取らない」という約束。disclose.io が標準化を進めている。
致命的なポイント: safe harbor は「スコープ内 かつ ルール順守」のときだけ効きます。 スコープ外に触れた瞬間、あるいは禁止手法を使った瞬間、その保護は消え、ホワイトハッカーと法律で見た不正アクセス禁止法の問題に変わります。
4. 【実装】スコープ判定を“コードの不変条件”にする
「テストしてよいか」を人間の記憶に頼ると、いつか事故ります。プログラムの不変条件にしてしまいましょう。以下は、対象がスコープ内かを判定し、**外なら必ず止める(デフォルト拒否)**スコープガードです。out-of-scope は in-scope より優先し、ワイルドカードにも対応します。
"""scope_guard.py — バグバウンティのスコープ内かを判定し、外なら必ず止める。
設計意図: 「テストしてよいか」を人間の記憶ではなく、プログラムの不変条件にする。
スコープ定義(in/out)を唯一の真実源として、対象ホストを照合する。
out-of-scope への作業は safe harbor の外=違法になり得るため、デフォルト拒否。
"""
from __future__ import annotations
import sys
from dataclasses import dataclass
from fnmatch import fnmatch
from urllib.parse import urlparse
@dataclass(frozen=True, slots=True)
class Scope:
"""プログラムのスコープ。in/out はワイルドカード可(例: *.example.com)。"""
in_scope: tuple[str, ...]
out_of_scope: tuple[str, ...]
def host_of(target: str) -> str:
"""URL でもホスト名でも、判定対象のホストを取り出す。"""
parsed = urlparse(target if "//" in target else f"//{target}")
host = (parsed.hostname or "").lower()
if not host:
raise ValueError(f"対象からホストを特定できません: {target!r}")
return host
def is_authorized(target: str, scope: Scope) -> bool:
"""in-scope に一致し、かつ out-of-scope に一致しないときだけ True(デフォルト拒否)。"""
host = host_of(target)
# 除外が最優先:out-of-scope に一致したら、in-scope を見るまでもなく拒否。
if any(fnmatch(host, pattern) for pattern in scope.out_of_scope):
return False
return any(fnmatch(host, pattern) for pattern in scope.in_scope)
def main(argv: list[str]) -> int:
if len(argv) != 2:
print("usage: python scope_guard.py <target-url-or-host>", file=sys.stderr)
return 2
# 実運用では各プログラムのポリシーから読み込む。ここは構造を示す例。
scope = Scope(
in_scope=("*.example.com", "api.example.com"),
out_of_scope=("blog.example.com", "*.corp.example.com"),
)
try:
authorized = is_authorized(argv[1], scope)
except ValueError as error:
print(f"判定不能: {error}", file=sys.stderr)
return 2
if authorized:
print(f"IN SCOPE: {argv[1]} — テスト可(プログラムのルールも必ず順守)")
return 0
print(f"OUT OF SCOPE: {argv[1]} — テスト禁止(safe harbor の外)", file=sys.stderr)
return 1
if __name__ == "__main__":
raise SystemExit(main(sys.argv))
python scope_guard.py https://api.example.com # IN SCOPE: ... — テスト可
python scope_guard.py https://blog.example.com # OUT OF SCOPE: ... — テスト禁止
python scope_guard.py https://victim.test # OUT OF SCOPE(in-scope に一致しない=デフォルト拒否)
設計の勘所は、**「除外(out-of-scope)を最優先し、明示的に許可された対象だけを通す(デフォルト拒否)」**こと。セキュリティの基本原則“fail-safe defaults / 最小権限”を、そのまま倫理の担保に使っています。
5. 正しいワークフロー — 偵察から協調的開示まで
報奨を得るまでの一連の流れを、HackerOne の協調的脆弱性開示(CVD)に沿って整理します。
1. スコープ精読 in/out・禁止手法・safe harbor を読む(ここが9割)
2. 偵察 in-scope の資産・機能を把握(公開情報の範囲で)
3. 発見 脆弱性の“仮説”を立てる(A01 アクセス制御が最頻出)
4. 検証(PoC最小) 再現に必要な最小限だけ。破壊せず・データを持ち出さない
5. 報告 プラットフォーム経由で、伝わるレポートを提出
6. トリアージ 企業/トリアージャが深刻度を判定(VRT 等)
7. 報奨 深刻度に応じた支払い
8. 協調的開示 修正後、企業と“合意の上で”公表(無断公表しない)
特に 4(検証) が分かれ目です。「証明に必要な最小限」を超えて、データを抜く・他ユーザーに影響を出す・サービスを止める——これらはルール違反であり、ホワイトの一線を越えます。“侵入できることを示す”だけで止めるのがプロです。
6. 伝わるレポートと深刻度
技術力と同じくらい、修正する開発者に伝わる報告書が評価を分けます。深刻度は Bugcrowd VRT や CVSS で共通言語化されており、これに沿って自己評価を添えると話が早く進みます。
レポートの骨子は**「結論から・再現可能に・影響を具体的に」**。
## 概要(Summary)
注文APIに認可不備(IDOR / A01:2025)。一般ユーザーが ID 改変だけで
他人の注文情報を閲覧できる。
## 深刻度(Severity)
Bugcrowd VRT: P2 相当 / CVSS 4.0 自己評価ベクタを併記(最終判定はベンダー)。
## 再現手順(Steps to Reproduce)
1. 一般ユーザーでログイン
2. GET /api/orders/1001 を GET /api/orders/1000 に変更
3. 他人の注文が返ることを確認(※自分のテスト用に作った注文間で確認)
## 影響(Impact)
全顧客の注文履歴(氏名・住所・購入物)が閲覧可能。情報漏えい。
## 想定される修正(Suggested Fix)
サーバ側で「注文の所有者 == 認証ユーザー」を必ず検証する。
## 証跡(Proof of Concept)
リクエスト/レスポンス例(実データはマスキング)。破壊的操作はしていない。
ここで例にした IDOR(A01:2025 アクセス制御の不備) は、バグバウンティで最も多く見つかり、かつ自動ツールでは見抜けない典型です。検出の考え方はNext.js × Supabase の認可不備・IDOR検出に詳しくまとめています。
7. 日本から参加するときの注意
- 言語:多くのプログラムは英語。レポートも英語が基本。テンプレート化すれば十分戦えます。
- 税務:報奨は所得です。確定申告など、日本の税制に従って適切に処理してください(本記事は法務・税務助言ではありません。専門家に確認を)。
- 法律:スコープ内でも、日本から実行する行為に日本法が及び得ます。**「許可された範囲・許可された手法」**を絶対に逸脱しないこと。
8. やってはいけないこと(保存版チェックリスト)
- ❌ スコープ外の資産に触れる(safe harbor の外=違法リスク)。
- ❌ DoS/高負荷スキャンでサービスを止める。
- ❌ 他ユーザーの実データを閲覧・持ち出す(PoCは自分のテストアカウント間で)。
- ❌ 無断公表・SNSでの暴露(協調的開示の合意前は黙る)。
- ❌ 企業に**「払わないと公開する」**と迫る(脅迫=犯罪)。
- ✅ スコープとルールを読む → 最小限で検証 → 伝わる報告 → 合意の上で開示。
9. まとめ — “許可された本物”で、実績と報奨を積む
- バグバウンティは安全地帯③。許可があるから合法で、スコープ外は違法。
- 最初に磨くのは攻撃力よりスコープと safe harbor を読む力。コードでデフォルト拒否を担保する。
- ワークフローは偵察→最小限の検証→伝わる報告→協調的開示。破壊せず・持ち出さず・無断公表しない。
バグバウンティの実績は、資格と並ぶ**“手を動かした証明”**として市場で強く効きます(→ 資格はどれを取るべきか)。その実力がどうキャリア・年収・案件につながるかは、ホワイトハッカーの仕事・年収・キャリアで解説します。
企業の方へ: 「自社でもバグバウンティやVDPを始めたい」「その前に一度、本番前の脆弱性を専門家に診てほしい」——どちらも、設計を理解した人間の関与が必要な領域です。まず無料OSSで水平の穴を一掃し、設計でしか守れない縦のリスクを監査に回す、が最もコスト効率の良い順番です。