# バグバウンティの始め方【2026】HackerOne・Bugcrowdで合法的に脆弱性を見つけて報告する

> ホワイトハッカーが報奨を得る正規ルート＝バグバウンティの始め方を、公式（HackerOne／Bugcrowd／disclose.io）に忠実に解説。バグバウンティとVDPの違い、最重要のスコープと safe harbor の読み方、偵察→検証→報告→トリアージ→開示の正しいワークフロー、深刻度（Bugcrowd VRT）と伝わるレポートの書き方、そして“スコープ外を構造的に拒否する”スコープガードの実装まで。

- 公開日: 2026-06-28
- 著者: 友田 陽大
- タグ: セキュリティ, ホワイトハッカー, バグバウンティ, 倫理的ハッキング, 脆弱性開示
- URL: https://tomodahinata.com/blog/bug-bounty-getting-started-hackerone-bugcrowd-scope-report-disclosure-guide
- カテゴリ: ホワイトハッカー入門
- 総合ガイド: https://tomodahinata.com/blog/white-hat-hacker-ethical-hacker-how-to-become-certification-roadmap-guide

## 要点

- バグバウンティは『企業が許可した範囲（スコープ）だけを調べ、見つけたら報奨を得る』正規ルート。安全地帯③。許可があるからこそ合法で、スコープ外は safe harbor の外＝違法になり得る
- 最重要スキルは攻撃力ではなく『スコープと safe harbor を正確に読む力』。in-scope/out-of-scope、禁止手法（DoS・ソーシャルエンジニアリング・他者データ持ち出し）を守って初めて法的保護が効く
- ワークフローは偵察→発見→最小限のPoC検証→報告→トリアージ→報奨→協調的開示（CVD）。破壊せず・データを持ち出さず・無断公表しない。これがホワイトの最低条件
- 深刻度は Bugcrowd VRT などの業界標準で共通言語化されている。報告は『結論から・再現可能に・影響を具体的に』。修正する開発者に伝わるレポートが評価を分ける
- コードで倫理を担保する：対象がスコープ内かを判定し、外なら必ず止める“スコープガード”を実装。テスト可否を人間の記憶ではなくプログラムの不変条件にする（デフォルト拒否）

---

自分のラボとCTFで力をつけたら、いよいよ**本物の対象**に触れる番です。そして、それを**完全に合法**に行える唯一の入口が、**バグバウンティ**です。

バグバウンティは、企業が「この範囲なら調べてよい、見つけたら報奨を払う」と公開する制度。[ホワイトハッカーと法律](/blog/ethical-hacker-law-japan-unauthorized-access-act-active-cyber-defense-disclosure-guide)で定めた**安全地帯③（許可されたスコープ）**そのものです。本記事は、報奨を得るための正規の歩き方を、公式（HackerOne／Bugcrowd／disclose.io）に忠実に解説します。

> これは[ホワイトハッカーになるには【完全ロードマップ】](/blog/white-hat-hacker-ethical-hacker-how-to-become-certification-roadmap-guide)の実戦・収益化パートを深掘りするスポークです。

---

## 1. バグバウンティと VDP の違い

まず用語を整理します。似て非なる2つがあります。

| 制度 | 目的 | 報奨 | 性格 |
|---|---|---|---|
| **バグバウンティ（Bug Bounty）** | 脆弱性を見つけてもらう | **あり**（深刻度に応じた金銭） | 競争的・収益化できる |
| **VDP（脆弱性開示プログラム）** | 報告を安全に受け付ける窓口 | 原則なし（謝辞・殿堂入り等） | 善意の報告の“受け皿” |

[Bugcrowd の定義](https://www.bugcrowd.com/glossary/vulnerability-disclosure-program-vdp/)でも、VDPは「報告のための安全な経路を提供する」もの、バグバウンティは「報奨で研究者を動機づける」ものと区別されます。**初心者はまずVDPや入門者向けプログラムで“報告の作法”を覚え、慣れたら報奨つきへ**進むのが安全です。

---

## 2. プラットフォーム — どこで始めるか

個人がいきなり企業と直接やりとりするのは大変です。間に立つのが**バグバウンティ・プラットフォーム**です。

- **[HackerOne](https://www.hackerone.com/)** — 最大手。多数の有名企業のプログラムが集まる。協調的脆弱性開示（CVD）の運用が整備されている（[HackerOne CVD](https://docs.hackerone.com/en/articles/9829406-coordinated-vulnerability-disclosure)）。
- **[Bugcrowd](https://www.bugcrowd.com/)** — もう一つの大手。深刻度評価の業界標準 **[VRT（Vulnerability Rating Taxonomy）](https://bugcrowd.com/vulnerability-rating-taxonomy)** を公開している。
- **[Internet Bug Bounty](https://www.hackerone.com/)** — OSS／ソフトウェアサプライチェーンを対象にした共同プログラム。

プラットフォームは、**スコープの提示・報告の受付・トリアージ・報奨の支払い・開示の調整**までを仲介します。研究者は登録し、各プログラムの**スコープとルール**を読んでから動きます。

---

## 3. 最重要スキルは「スコープを正確に読む力」

意外に思うかもしれませんが、バグバウンティで最初に磨くべきは**攻撃力ではなく「スコープと safe harbor を正確に読む力」**です。ここを誤ると、報奨どころか違法行為になります。

各プログラムは、必ず次を明示します。

- **In-Scope** — テストしてよい資産（ドメイン、API、アプリ）。`*.example.com` のようなワイルドカード指定もある。
- **Out-of-Scope** — テスト禁止の資産（第三者サービス、特定サブドメイン等）。
- **禁止される手法** — **DoS／DDoS、ソーシャルエンジニアリング、物理侵入、他ユーザーの実データの持ち出し**などは、多くのプログラムで明確に禁止。
- **safe harbor（セーフハーバー）** — 「スコープとルールを守る善意の研究に対しては法的措置を取らない」という約束。[disclose.io](https://disclose.io/) が標準化を進めている。

> **致命的なポイント：** **safe harbor は「スコープ内 かつ ルール順守」のときだけ効きます。** スコープ外に触れた瞬間、あるいは禁止手法を使った瞬間、その保護は消え、[ホワイトハッカーと法律](/blog/ethical-hacker-law-japan-unauthorized-access-act-active-cyber-defense-disclosure-guide)で見た不正アクセス禁止法の問題に変わります。

---

## 4. 【実装】スコープ判定を“コードの不変条件”にする

「テストしてよいか」を人間の記憶に頼ると、いつか事故ります。**プログラムの不変条件**にしてしまいましょう。以下は、対象がスコープ内かを判定し、**外なら必ず止める（デフォルト拒否）**スコープガードです。out-of-scope は in-scope より優先し、ワイルドカードにも対応します。

```python
"""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))
```

```bash
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）](https://docs.hackerone.com/en/articles/9829406-coordinated-vulnerability-disclosure)に沿って整理します。

```text
1. スコープ精読   in/out・禁止手法・safe harbor を読む（ここが9割）
2. 偵察           in-scope の資産・機能を把握（公開情報の範囲で）
3. 発見           脆弱性の“仮説”を立てる（A01 アクセス制御が最頻出）
4. 検証(PoC最小)  再現に必要な最小限だけ。破壊せず・データを持ち出さない
5. 報告           プラットフォーム経由で、伝わるレポートを提出
6. トリアージ     企業/トリアージャが深刻度を判定（VRT 等）
7. 報奨           深刻度に応じた支払い
8. 協調的開示     修正後、企業と“合意の上で”公表（無断公表しない）
```

特に **4（検証）** が分かれ目です。「証明に必要な最小限」を超えて、データを抜く・他ユーザーに影響を出す・サービスを止める——これらはルール違反であり、ホワイトの一線を越えます。**“侵入できることを示す”だけで止める**のがプロです。

---

## 6. 伝わるレポートと深刻度

技術力と同じくらい、**修正する開発者に伝わる報告書**が評価を分けます。深刻度は [Bugcrowd VRT](https://bugcrowd.com/vulnerability-rating-taxonomy) や CVSS で共通言語化されており、これに沿って自己評価を添えると話が早く進みます。

レポートの骨子は**「結論から・再現可能に・影響を具体的に」**。

```markdown
## 概要（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検出](/blog/nextjs-supabase-idor-broken-authorization-rls-detection-guide)に詳しくまとめています。

---

## 7. 日本から参加するときの注意

- **言語**：多くのプログラムは英語。レポートも英語が基本。テンプレート化すれば十分戦えます。
- **税務**：報奨は所得です。確定申告など、日本の税制に従って適切に処理してください（本記事は法務・税務助言ではありません。専門家に確認を）。
- **法律**：スコープ内でも、日本から実行する行為に日本法が及び得ます。**「許可された範囲・許可された手法」**を絶対に逸脱しないこと。

---

## 8. やってはいけないこと（保存版チェックリスト）

- ❌ **スコープ外**の資産に触れる（safe harbor の外＝違法リスク）。
- ❌ **DoS／高負荷スキャン**でサービスを止める。
- ❌ **他ユーザーの実データ**を閲覧・持ち出す（PoCは自分のテストアカウント間で）。
- ❌ **無断公表**・SNSでの暴露（協調的開示の合意前は黙る）。
- ❌ 企業に**「払わないと公開する」**と迫る（脅迫＝犯罪）。
- ✅ スコープとルールを読む → 最小限で検証 → 伝わる報告 → 合意の上で開示。

---

## 9. まとめ — “許可された本物”で、実績と報奨を積む

- バグバウンティは**安全地帯③**。許可があるから合法で、**スコープ外は違法**。
- 最初に磨くのは攻撃力より**スコープと safe harbor を読む力**。コードで**デフォルト拒否**を担保する。
- ワークフローは**偵察→最小限の検証→伝わる報告→協調的開示**。破壊せず・持ち出さず・無断公表しない。

バグバウンティの実績は、資格と並ぶ**“手を動かした証明”**として市場で強く効きます（→ [資格はどれを取るべきか](/blog/ethical-hacker-certification-comparison-ceh-oscp-security-plus-pentest-plus-toroku-sec-guide)）。その実力がどうキャリア・年収・案件につながるかは、[ホワイトハッカーの仕事・年収・キャリア](/blog/ethical-hacker-career-path-salary-job-roles-freelance-guide)で解説します。

> **企業の方へ：** 「自社でもバグバウンティやVDPを始めたい」「その前に一度、本番前の脆弱性を専門家に診てほしい」——どちらも、設計を理解した人間の関与が必要な領域です。まず無料OSSで水平の穴を一掃し、設計でしか守れない縦のリスクを監査に回す、が最もコスト効率の良い順番です。

---

### 参考（公式一次情報）

- [HackerOne](https://www.hackerone.com/)／[HackerOne 協調的脆弱性開示（CVD）](https://docs.hackerone.com/en/articles/9829406-coordinated-vulnerability-disclosure)
- [Bugcrowd](https://www.bugcrowd.com/)／[Bugcrowd VRT（深刻度分類）](https://bugcrowd.com/vulnerability-rating-taxonomy)／[VDPとは](https://www.bugcrowd.com/glossary/vulnerability-disclosure-program-vdp/)
- [disclose.io（safe harbor 標準化）](https://disclose.io/)／[IPA 脆弱性関連情報の届出](https://www.ipa.go.jp/security/vuln/report/)／[JPCERT/CC](https://www.jpcert.or.jp/)