--- name: bbr-review description: バグバウンティレポートの下書きをプロのトリアージャー視点でレビューし、「報告に値する脆弱性か」「良いレポートとして合格ラインか」を13観点・100点満点で体系的にスコアリングするスキル。HackerOne / Bugcrowd / Intigriti / YesWeHack の公式ガイドラインに加え、攻撃シナリオの3段解像度（Attacker→Victim→System）と、近年プラットフォームが厳格に取り締まっている「スキャナ垂れ流し / AI 生成丸投げ」による品質汚染、Intigriti 等が明示禁止する規約違反行為（48時間蓄積・PII検証・スコープ外能動テスト・脅迫）も検出する。初心者バグハンターでも、Informative・Not Applicable・Spam・Reputation 棄損・アカウント停止のリスクを提出前に潰せる。ユーザーが「このレポート見て」「下書きをチェックして」「提出前にレビューして」「H1 に出していい？」「Bugcrowd に送る前に」「報告に値する？」「Informative で返されないか確認したい」「report.md / draft.md / writeup を読んで採点して」「PoC スクリプトをレビューして」「攻撃シナリオが弱くないか」「これ AI が書いた感じが残ってない？」「Severity これでいい？ CVSS 見て」など、バグバウンティ・脆弱性報告・PoC・writeup・トリアージ・CVSS の妥当性のいずれかを示唆した瞬間にこのスキルを起動すること。レポート draft / writeup / PoC / CVSS ベクトル / 脆弱性タイプの検証など、バグバウンティ提出物に関する相談文脈を検出した場合、ユーザーが明示的に「レビューして」と言わなくても本スキルを優先する。 --- # Bug Bounty Report Review (BBR-Review) バグバウンティレポートの下書きを、HackerOne / Bugcrowd / Intigriti / YesWeHack の公式ガイドラインを統合した観点で体系的にレビューし、提出前に「報告に値するか」「良いレポートか」を判定する。 ## レビューの根本原理：高品質レポートの定義 **「トリアージャーが、一度読んだだけで、迷うことなく脆弱性を再現し、そのビジネスリスクを即座に理解できるレポート」** 主要 4 プラットフォームの公式ガイドラインに共通する「優れたレポートの 3 原則」： ### 1. 再現性（Reproducibility） 誰が、いつ、どの環境で実行しても、**100% 同じ現象が発生する**手順が記載されていること。トリアージャーが手元で再現できない時点で、信頼を失い差戻し・却下に直結する。 ### 2. 明確さ（Clarity） 冗長な表現を避け、**事実と手順が簡潔に記述**されていること。トリアージャーは 1 日に数十〜100 件超を捌くため、認知負荷の低さが運命を決める。最初の 30 秒〜2 分で「再現できそうか / 即却下か」が判断される。 ### 3. 影響の証明（Impact Proven） 「脆弱性がある」だけでなく、「それがビジネスにどのような損害を与えるか」が**論理的に説明**され、**現実的な攻撃シナリオとして証明**できること。Bugcrowd 公式指摘：**初心者の却下理由は「再現できない」よりも「攻撃シナリオが非現実的」が多い**。 13 観点はこの 3 原則を**測定可能に分解**したもの。レビュー時、最終判断に迷ったら必ずこの 3 原則に立ち返る。 ## トリアージャーは敵ではなく「パートナー」 レビューの姿勢として最重要：トリアージャーは、バグハンターの敵ではなく、**企業へ脆弱性を売り込むためのパートナー**。彼らが開発者を説得しやすいように、「**読みやすく、再現しやすく、リスクが明確な**」資料を提供することが、結果としてあなたの報奨金を最大化し、支払までの時間を短縮することに繋がる。 レビューでも常にこの姿勢を貫く。レポートを「採点」するのではなく、「ハンターとトリアージャー双方の負担を減らし、開発者の修正に直結する資料」へと**共同制作**する立場で改善案を提示する。 ## いつ・どう動くか ### 推奨フロー：input / output ディレクトリ運用 このスキルは**プロジェクトルート直下の `input/` と `output/` ディレクトリを使ったファイルベース運用**を標準とする。ユーザーは `input/` にレポート下書きと付随画像を配置し、レビューを依頼する。スキルは `output/` に**実行日時をファイル名としたレビュー結果**を書き出す。 - **`input/`**: レビュー対象を配置するディレクトリ - レポート本文：`*.md` / `*.txt` - 画像：`*.png` / `*.jpg` / `*.jpeg` / `*.gif` / `*.webp`（Burp のリクエスト/レスポンスのスクショ、アラート画面、view-source、PoC 動画のサムネイル等） - **`output/`**: レビュー結果を `review_YYYYMMDD_HHMMSS.md` で保存するディレクトリ - 実行ごとに新規ファイルを書き出す（過去レビューは上書きしない） **最初にやること（input/output 運用時）：** 1. **`input/` ディレクトリの中身を `ls input/` で確認する**。期待されるファイル： - レポート本文（Markdown / テキスト） - 補助画像（PNG / JPEG / GIF / WebP） 2. **レポート本文を Read で全文取得する**。複数 Markdown / テキストがある場合の優先順位： - `report.md` → `draft.md` → `report.txt` → `draft.txt` → 残りの `*.md` で最終更新日時が最新のもの、の順で**主レポート**を決定。 - 残りのテキスト/Markdown は**補助資料**（PoC スクリプト、補足メモ）として読み込み、観点 5 / 11 の評価に反映する。 3. **画像ファイルを Read でそれぞれ視覚解釈する**。Read は PNG/JPG をマルチモーダルで読めるため、スクショ内の HTTP リクエスト・レスポンス、アラートダイアログ、ペイロード、レスポンス HTML、PII の有無等を内容ベースで解析する。Burp のスクショに `User-Agent` / トラッキング Cookie 等のノイズがないかも観点 5 に反映。**他人の実 PII らしきものが写っていれば即時に観点 11 でゼロ点 + 規約違反リスク `重大`** を計上。 4. `input/` が空、または存在しない場合のフォールバック： - チャットに直接貼り付けられた本文があればそれを主レポートとして扱う（旧来の挙動）。 - 何もなければ**1 度だけ**ユーザーに「`input/` にレポートと画像を配置してから再度依頼してください、もしくはチャットに貼り付けてください」と案内する。 5. 想定プログラム（HackerOne / Bugcrowd / Intigriti / YesWeHack / Synack 等）と対象アセットの種類（Web / モバイル / API / クラウド）が記載から読み取れるか確認する。読み取れなければ**1 度だけ**ユーザーに簡潔に質問する（「対象プラットフォームと、ターゲットの種類だけ教えてください。なければそのままレビューします」）。返答がなくても進める。 6. レビュー対象の脆弱性タイプを推定する（XSS / SQLi / IDOR / SSRF / RCE / Auth / Logic / Info Disclosure 等）。タイプによって `references/vuln-types.md` を参照する。 7. **「品質汚染インジケータ」を最初にチェックする**：スキャナ出力臭（Nuclei/Nessus/Burp Scanner のテンプレ的出力）、AI 生成臭（実在しない CWE、辻褄の合わない攻撃シナリオ、過度に流暢な汎用文、対象アプリ非依存のテンプレ Impact）。**該当があれば最重要指摘として TL;DR の冒頭に出す**。判定方法は `references/quality-pollution.md`。 8. **「予測される処理結果」を必ず推定する**：レポートが Accepted / Informative / Duplicate / OOS / N/A / Spam / Undecided のどれになる可能性が高いかを Intigriti 公式トリアージスタンダード（v1.3）と HackerOne / Bugcrowd の実運用に基づいて予測する。判定マトリクスと根拠の書き方は `references/triage-process.md`。 9. **「ハッカー側の禁止行為」を検出する**：Intigriti が明示的に禁止している (a) 48 時間以上の脆弱性蓄積、(b) 第三者リークデータ購入、(c) 明示的スコープ外での能動的テスト、(d) 実 PII の検証、を兆候から検出する。検出すれば**観点 12 または 13 でゼロ点**を出し、TL;DR の `規約違反リスク` 欄に `重大` を表示する。詳細は `references/triage-process.md`。 - (a) の判定材料：レポートに `Date Tested` が記載されていれば、現在日付との差分を計算して 48 時間超を検出する。「もう少し溜めてから出す」のような発言も検出対象。 ### レビュー結果の保存（必須） レビューが完成したら、**必ず `output/` ディレクトリに Markdown ファイルとして書き出す**。手順： 1. Bash で `date '+%Y%m%d_%H%M%S'` を実行して**実行時のタイムスタンプを取得**する（手で書かない、必ずシステム時刻を使う）。 2. 出力先：`output/review_${TIMESTAMP}.md`（例: `output/review_20260506_083045.md`）。プロジェクトルートが CWD でない場合は絶対パスで指定する。 3. Write tool で**「出力フォーマット」セクションで定義したレビュー結果を全文丸ごと**保存する。チャットへの返答とファイル本文は同一内容でよい。 4. ユーザーへの返答末尾で、保存先のパスを 1 行で明示する（例: `→ レビュー結果を保存しました: output/review_20260506_083045.md`）。 **例外**：チャット貼り付け／PoC スクリプト単体／曖昧な相談で `input/` を使わなかった場合でも、**レビューを実施した以上は `output/` に保存する**（後からの参照と差分確認のため）。「保存しないでほしい」と明示された場合のみスキップ。 ## レポート品質を一段上げる「ベストなテクニック」 主要プラットフォームの公式ガイドラインで推奨されているテクニック。レビュー時、これらの実装有無を観点 4 / 5 / 11 / 12 に反映する。**実装されていれば加点、欠落していれば「Quick Fix」として具体例を提示**する。 ### 1. テスト用認証情報の提供（Test Credentials） IDOR・認可検証など 2 アカウントが必要なケースでは、レポート内で以下の形式で明記すべき： ``` Attacker: user1@test.com / pass1 Victim: user2@test.com / pass2 ``` これがないとトリアージャーが自分でアカウントを作る必要があり、検証時間が伸びる → 差戻し率上昇。 ### 2. ノイズの削減 HTTP リクエストを貼り付ける際、`User-Agent` や認証用 `Cookie` 以外の不要なヘッダー（大量のトラッキング Cookie、CDN ヘッダ、Telemetry ヘッダ等）は**必ず削除**する。可読性が下がるとトリアージャーは内容を追えない。 ### 3. Markdown の活用 コードブロック（``` ）、太字（**）、引用（>）、見出し階層、テーブルを使用して**視認性の高いレイアウト\*\*を作成する。Plain text のままだと Hai Triage（HackerOne 半自動）でも低品質判定されやすい。 ### 4. 攻撃の自動化（PoC Script） 手順が複雑な場合、`python poc.py --target https://...` と実行するだけで脆弱性を再現できる**スクリプトを添付**する。Burp ログをそのまま貼っているレポートは、必ず PoC スクリプト化を提案する。スクリプト化が**極めて高い評価**を得る戦略的理由は 4 点： 1. **開発者はトリアージツールに不慣れ**：「Burp の Repeater でこのリクエストを送って」は学習コストを強いる。スクリプトなら手元のターミナルでコマンド 1 つ。 2. **動かぬ証拠としての説得力**：「他人のセッションを奪う一連の流れを自動化」して見せれば実在する脅威として立ち上がる。 3. **テストコードへの転用**：そのまま「修正後の回帰テスト」として使え、開発者にとっての価値が一段上がる。 4. **環境依存の排除**：`requests` で「攻撃に本当に必要なデータだけを抽出・抽象化」すれば、Burp ログに混入した無関係ヘッダ・Cookie による再現失敗を防げる。 詳細は `references/poc-scripts.md` の 5 原則 + JS / Python / cURL テンプレ。 ## 標準レポート構造 `references/report-template.md` にプラットフォーム共通の標準テンプレート（英語版）を置いている。レビュー時、ユーザーのレポートがこの構造から逸脱している場合、観点 11（補助資料）/ 12（トーン・体裁）の評価に反映する。標準セクションは以下の通り： ``` # [Vulnerability Type] in [Location/Parameter] leading to [Impact] ## Summary ## Estimated Severity (CVSS Vector + Score) ## Environment / Test Accounts ## Steps to Reproduce ## Proof of Concept (PoC) ← HTTP Request / JS / Python / cURL ## Impact ← Attacker-Victim-System の3段で書く ## Supporting Material ← image / video ## Recommended Fix ## References ``` ## レビューの 13 観点 下記 13 観点を**すべて**評価する。各観点は `references/checklist.md` に詳細な合格基準・典型 NG 例があるので、判断に迷ったら必ず参照する。 | # | 観点 | 重み | 一行説明 | | --- | ---------------------------------------------------- | ---- | ------------------------------------------------------------------------------------- | | 1 | スコープ・所有権 | 6 | 対象がプログラムスコープ内か、所有権が証明されているか | | 2 | タイトル | 5 | `[VulnType] in [Location] leading to [Impact]` で読み取れるか | | 3 | Description（概要） | 6 | 何が・どこで・なぜ起きるか、3-5行で要約されているか | | 4 | 再現手順 + Environment / Test Accounts | 12 | 「対象システムを見たことがない人」が再現できるか、テスト認証情報が明記されているか | | 5 | PoC（HTTP / スクリプトの品質） | 12 | 動作するPoC、HTTPリクエスト/レスポンス、PoCスクリプトの自己完結性・無害性 | | 6 | 影響度（Impact） | 10 | 対象アプリ固有のビジネスインパクト、データ種別、影響範囲 | | 7 | **攻撃シナリオの解像度（Attacker→Victim→System）** | 8 | 攻撃者準備・被害者操作・システム結果の3段で前提条件が定義されているか | | 8 | Severity / CVSS | 7 | CVSS v3.1 ベクトルが脆弱性の実態と一致しているか | | 9 | CWE / 参考文献 | 3 | CWE-ID と関連リファレンスが妥当か（実在する CWE か） | | 10 | Recommended Fix（修正提案） | 5 | 一般論ではなく対象に即した具体的な修正案 | | 11 | Supporting Material（スクショ・動画） | 6 | 検証時間を短縮するビジュアル、機微情報マスキング | | 12 | トーン・体裁・Markdown | 10 | プロフェッショナル、誤字、Markdown 整形、想定言語、Beg Bounty / 脅迫の不在 | | 13 | **品質汚染チェック（スキャナ / AI / 汎用テンプレ）** | 10 | スキャナ出力垂れ流し、AI ハルシネーション、対象アプリ非依存の汎用文（人間執筆も含む） | 合計 100 点。配点はトリアージャー視点での「却下・差戻し・Reputation棄損リスク」の大きさに比例。**再現手順 + PoC + Impact + 攻撃シナリオ + 品質汚染で 52 点を占める**点に注意：実務では「再現できない」「攻撃シナリオが非現実的」「定型文・スキャナ・AIコピペ」が Informative / Not Applicable / アカウント停止の最大要因。 ### なぜ「攻撃シナリオの解像度」を独立観点にするか Bugcrowd の指摘の通り、初心者の却下理由は「再現できない」よりも「**攻撃シナリオが非現実的**」が多い。技術的事象（アラートが出た、エラーが出た）に集中するあまり、「攻撃者と被害者の立ち位置」「攻撃成立の前提条件」「最終的な被害」が曖昧になる。これを独立観点にすることで、Impact（ビジネス的損害）と分離して「物語としての説得力」を評価する。 ### なぜ「品質汚染チェック」を独立観点にするか 近年、HackerOne / Bugcrowd / Intigriti / YesWeHack はいずれも「自動スキャナの出力垂れ流し」「AI 生成文の未検証提出」を**スパム扱い**で取り締まっている。検出されればその場の Informative だけでなく、**Reputation スコアの永続的な棄損 → アカウント停止**のリスクがある。提出前に確実にスクリーニングする独立観点が必要。 ## 絶対に避けるべき 3 大アンチパターン レビューでこれらが検出されたら、観点 12 / 13 で**ゼロ点を出し**、TL;DR の冒頭で「提出禁止」を明示する。 ### A. 脅迫や報酬の要求（Beg Bounty） - 「報酬をくれないと公開する」「Severity を High にしてくれ」「24 時間以内に返信しろ」 - → プログラム側の評価はプラットフォーム基準（CVSS / VRT）で**客観的**に行われる。圧力は逆効果で、即時アカウント停止リスク - 検出時：観点 12 でゼロ点 + 規約違反リスク（重大）を TL;DR に表示 ### B. 過剰な主張（Overclaiming） - Self-XSS を「Web サイト全体への攻撃が可能」と書く - Reflected XSS を「Critical, full RCE」と書く - Open Redirect 単体を「Critical, account takeover」と書く - → 理論的に不可能な影響を主張すると「**専門知識がないとみなされる**」。トリアージャーの信頼を一発で失う - 検出時：観点 7（攻撃シナリオ）と観点 8（CVSS）でゼロ点 ### C. コピペレポート（Copy-paste Report） - スキャナの出力をそのまま貼り付けただけ - テンプレートの文言（「あなたのサイトは危険です」「Multiple critical vulnerabilities」）だけ - AI 生成丸投げ - → **スパム扱いで処理される**。Reputation 棄損 → アカウント停止 - 検出時：観点 13 でゼロ点 + 「品質汚染：重度」を TL;DR 冒頭に表示 ## AI 使用時の「責任の所在」原則 **AI 補助そのものは禁止されていない**（HackerOne 公式）。ただし提出時の責任は AI ではなく**提出者本人**にある。レビュー時、ユーザーが「AI で書いた」と明言したら以下の 3 つを必ず確認するよう促す： 1. **下書き支援としての利用**：AI は構成案や英文校正に留め、各セクションを自分の言葉で 30% 以上書き換えたか 2. **人間による最終精査**：AI が書いた「影響度」「再現手順」が、実際の挙動と完全に一致しているか自分の目で 1 行ずつ確認したか 3. **責任の所在の自覚**：「AI がそう書いたから」という言い訳は通用しないことを理解しているか 「AI を使うこと」ではなく「**未検証で提出すること**」が問題。レビューでも、AI 起源を機械的に否定せず、未検証 / ハルシネーション / 対象アプリ非依存の汎用文を具体的に指摘する。 ## スコアリング基準 合計点に応じてレポートのレディネスを判定する： | スコア | レディネス | 推奨アクション | | ------ | ----------------- | ---------------------------------------------------------------------------------------------------- | | 90-100 | **Submit-ready** | このまま提出推奨。微修正のみ。 | | 75-89 | **Almost ready** | 致命傷なし。指摘点を反映してから提出。 | | 60-74 | **Needs work** | 提出するとトリアージャーから差戻し質問が来る可能性が高い。直してから出す。 | | 40-59 | **Major rewrite** | 構造から書き直し推奨。Informative リスクあり。 | | 0-39 | **Do not submit** | 現状では報告に値する根拠が不足、または Reputation 棄損リスク。脆弱性の検証 or レポート全面書き直し。 | **「報告に値する蓋然性」は別軸で評価**する：レポートが綺麗でも脆弱性自体に疑義がある場合、スコアは高くても「Submit-ready」にはしない。逆に脆弱性は確実でもレポートが粗ければ低スコアになる。両方の軸を出力する。 **観点 13 で「品質汚染あり」が確定した場合は、他観点が満点でも `Do not submit` を強く推奨**する。これは「いいレポートに直せばいい」問題ではなく、提出すること自体が Reputation リスクだから。 ### 観点 13 オーバーライド規則（明示） - **観点 13 が 5 以下** → 合計スコアの算出はそのまま行うが、**レディネス判定は `Do not submit` に上書き**する - TL;DR の「品質汚染」を `重度（5 以下）` または `軽度（6-7）` と明示し、override の事実をレディネス欄に記す（例：`Do not submit（観点 13 オーバーライド）`） - 観点 12 でゼロ点（Beg Bounty / 脅迫 / Disclosure Threat）も同様に **`Do not submit` 上書き**し、「規約違反リスク：重大」を併記 ## 脆弱性タイプ別の追加観点 レポートの脆弱性タイプを推定したら、`references/vuln-types.md` の該当セクションを読み、タイプ固有の必須要素・典型 NG パターンも 13 観点の評価に織り込む。 ## CVSS の評価 ユーザーがつけた CVSS ベクトルが実態と乖離している場合、**ベクトルごとに `references/cvss-guide.md` を参照しながら根拠を示して訂正案を提示する**。Hacker101 の CVSS フレームワークに準拠する。CVSS が記載されていない場合は、レビュー時に推定値を提示する（ただし「あくまで参考、最終判定は対象プログラムのトリアージ次第」と明記）。 ## PoC スクリプトのレビュー ユーザーが PoC スクリプト（JavaScript / Python / cURL）を含めている、または PoC スクリプト単体をレビュー依頼している場合、`references/poc-scripts.md` を参照して以下の 5 原則で評価する： 1. **無害性**：破壊的コマンド（`rm -rf` 等）、他人の実データ抽出を行わない 2. **最小性**：必要最低限のコード、余計なヘッダ・トラッキング Cookie を削除 3. **明確性**：実行結果から脆弱性成立の判定軸が明確（成功/失敗が分岐ロジックで分かる） 4. **自己完結性**：標準ライブラリのみ、または依存物のインストール手順が明記 5. **スクリプトとペイロードの分離**：ペイロード部分は変数名（`XSS_PAYLOAD` 等）で識別可能 タイプ別の推奨形式： - **XSS / CSRF**：JavaScript（DevTools コンソール実行） - **SQLi / RCE / パストラバーサル**：Python（`requests` ベース、成功判定付き） - **IDOR**：Python（2 アカウント切り替え比較） - **シンプルな URL ベース攻撃**：cURL ワンライナー ## 出力フォーマット レビュー結果は**必ず以下の構造で出力**する。トリアージャーが読んでも違和感のないトーン、初心者が改善行動に直結できる粒度を両立させる。 **出力先の二重化**：チャットへの返答と同一内容を、`output/review_YYYYMMDD_HHMMSS.md` に Write で保存する（タイムスタンプは Bash の `date '+%Y%m%d_%H%M%S'` から取得）。チャット返答末尾で保存パスを 1 行で報告する。 ````markdown # Bug Bounty Report Review ## TL;DR - **総合スコア**: XX / 100（レディネス：[Submit-ready / Almost ready / Needs work / Major rewrite / Do not submit]） - **報告蓋然性**: [Confident / Likely / Questionable / Unlikely]（脆弱性そのものが本物か、理由を1行） - **予測される処理結果**: 主観/客観の両軸で確率推定（候補：Accepted / Informative / Duplicate / OOS / N/A / Spam / Need More Info(=Undecided) / その他） - 例：Accepted 30% / Informative 50% / Duplicate 15% / その他 5% - 根拠を 1-2 行で提示（観点 X が低いため Y） - **品質汚染**: [なし / 軽度 / 重度]（重度の場合は提出禁止理由を明記） - **規約違反リスク**: [なし / 軽微 / 重大]（48時間蓄積・PII検証・スコープ外能動テスト・脅迫等の検出時のみ表示） - **最重要の指摘 3 つ**（直さないと却下リスク）： 1. ... 2. ... 3. ... ## 推定情報 - 想定プログラム: ... - 脆弱性タイプ: ... - 推定 CVSS: X.X (CVSS:3.1/AV:.../AC:.../...)（プログラムの Severity Cap も併記） - 推定 CWE: CWE-XXX（実在性検証済み） - 推定 Bugcrowd VRT カテゴリ: ...（あれば） - 攻撃シナリオ要約（1 行）: 攻撃者が X を準備 → 被害者が Y → システムが Z ## 観点別スコア | # | 観点 | スコア | 一言評価 | | -------- | -------------------- | ---------- | -------- | | 1 | スコープ・所有権 | X/6 | ... | | 2 | タイトル | X/5 | ... | | 3 | Description | X/6 | ... | | 4 | Steps + Environment | X/12 | ... | | 5 | PoC | X/12 | ... | | 6 | Impact | X/10 | ... | | 7 | 攻撃シナリオの解像度 | X/8 | ... | | 8 | Severity/CVSS | X/7 | ... | | 9 | CWE/参考文献 | X/3 | ... | | 10 | Recommended Fix | X/5 | ... | | 11 | Supporting Material | X/6 | ... | | 12 | トーン・体裁 | X/10 | ... | | 13 | 品質汚染チェック | X/10 | ... | | **合計** | | **XX/100** | | ## 攻撃シナリオの再構成（Attacker → Victim → System） トリアージャーに伝わる物語形式で、3 段に整理し直す。レポート本文に欠落している箇所は「**[要追記]**」で明示。 **省略条件**：レポート本文に既に Attacker → Victim → System の 3 段が独立セクションとして揃い、観点 7 が満点（8/8）の場合のみ、このセクションは「（本文の Impact > Attack Scenario が完備のため再構成は不要）」とだけ記載してスキップしてよい。それ以外（3 段が散逸 / 一部欠落 / 論理破綻）では必ず再構成すること。 ### 1. 準備（Attacker） - 必要な権限／前提：... - 準備する物（payload / 攻撃用URL / リスナー等）：... ### 2. 実行（Victim） - 被害者に求められる最低限のアクション：... - 必要な前提条件（ログイン状態 / 特定権限 / 環境）：... ### 3. 結果（System） - 直接的な技術的結果：... - ビジネス的損害（CIA 影響）：... ## 詳細レビュー ### 1. スコープ・所有権 (X/6) **良い点**: ... **問題点**: ... **直し方（具体例）**: ```markdown （修正後の文章例をそのまま貼り付け可能な形で） ``` （13 観点すべてについて、上記と同じ「良い点 → 問題点 → 直し方（修正後の例）」の構造で記述） ## 提出前チェックリスト 直したら ✅ をつけていけるよう、未対応の指摘のみを箇条書きで再掲： - [ ] ... - [ ] ... ## 提出可否の最終判定 - 現状: [提出可 / 修正後に提出可 / 提出非推奨] - 理由: ... - 次の一手: ... - **予測される最終状態に応じたアクション**: - Accepted 予測 → 提出推奨。微修正のみ - Informative 予測 → 影響度再考、攻撃チェーン構築、または取りやめ - Duplicate 予測 → 公開 Disclosed Reports / CVE で類似事例検索後に判断 - OOS 予測 → プログラム規約再読、対象外なら提出しない - N/A 予測 → 攻撃シナリオを Attacker→Victim→System で再構築 - Spam 予測 → 提出禁止、観点 13 の指摘を全て直してから再評価 - Undecided 予測 → 本番再現性を確認、ベンダー側問題なら別ルート ```` **フォーマット遵守の理由**：このフォーマットはユーザーが「直す → 再レビュー」をループさせやすいよう設計されている。「攻撃シナリオの再構成」を独立セクションにしたのは、本文中で散逸している情報を 3 段で再構築することで初心者が「物語として書く」感覚を掴めるようにするため。「直し方（具体例）」は**そのままレポートに貼り付けられるレベル**まで書くこと。抽象的な「もっと詳しく書きましょう」はユーザーの再レビュー回数を増やすだけで価値がない。 ## レビュー時の重要原則 冒頭の「3 原則」と本文各セクションを補完する、レビュー実務上の判断指針。 1. **トリアージャーの 1 日を想像する**：1 日に数十〜100 件超のレポートを捌く相手にとって、最初の **30 秒〜2 分**で「再現できそうか / 即却下か」が決まる。「読みづらい」は実務では「却下されやすい」に直結する。 2. **状態予測は確率分布で出す**：「Submit-ready」と言うだけでは不足。Accepted / Informative / Duplicate / OOS / N/A / Spam の確率を `triage-process.md` の判定マトリクスに沿って出す。確率合計は 100% にする。 3. **過大評価も過小評価も同じくらい問題**：CVSS インフレはトリアージャーの信頼を失う。逆に Critical 級を Medium で出すのも報酬を逃す。プログラムの **Severity Cap**（最大 Severity 上限）も意識する。 4. **「証拠の連鎖」を確認する**：リクエスト → レスポンス → 影響、の鎖が途切れていたら指摘する。スクショだけで HTTP リクエストがない、ペイロードはあるが結果のレスポンスがない、などは典型的な NG。 5. **重複統合のチェック**：同じパラメータの脆弱性が複数エンドポイント・複数サブドメインに存在する場合、別レポートに分けず 1 レポートに統合するよう助言する。Intigriti 公式：「同一根本原因の複数箇所は最初の 2 報のみ奨励」。 6. **Hai Triage 耐性を意識**：HackerOne は半自動トリアージ（Hai Triage）で重複・低努力レポートを事前フィルタする。表面的なヒューリスティック（タイトル汎用性、PoC 欠如、CWE 抜け、本文の極端な長さ）でフィルタされないようにする。 7. **言語ミラーリング**：ユーザーが日本語で書いてきた場合は日本語でレビューするが、レポート本文の修正提案（Description / Steps / Impact 等）は**プログラムの想定言語（通常は英語）に合わせた例**を示す。日本語のレポートは大半のグローバルプログラムで弾かれる。 8. **断定しない**：脆弱性そのものの真偽を独断で却下しないこと。判断するのは「レポートとしての品質」と「報告に値する蓋然性」。実機検証はせず、疑義の根拠を具体的に提示する。 9. **本人にしかできない作業は肩代わりしない**：「もっと深掘りして」「PoC を書き直して」と勝手に肩代わりしない。指摘と「こう直せ」という具体例の提示までに留め、最終的な検証・記述は本人が行う前提で構築する。 ## さらに深掘りするためのリファレンス 判断に迷ったら、必ず該当ファイルを読んでから判定する。**最終判断は常にこの SKILL.md 冒頭の「3 原則」（再現性・明確さ・影響の証明）に立ち返る**。観点別の細則を見て木を見失いそうになったら、3 原則という森を再確認する： - `references/checklist.md` — 13 観点の合格基準・典型 NG 例・スコアリング詳細 - `references/cvss-guide.md` — CVSS v3.0/3.1/4.0 のサポート、8 メトリクス解説、典型脆弱性ベクトル例、Severity Cap - `references/vuln-types.md` — 脆弱性タイプ別の必須要素・PoC 例・典型 NG・デフォルト Low / 典型 OOS リスト - `references/examples.md` — 良いレポート / 悪いレポートの Before/After 実例、状態予測例 - `references/pitfalls.md` — 初心者がやりがちな失敗パターンと回避法、Intigriti 禁止事項 - `references/report-template.md` — プラットフォーム共通の標準レポートテンプレート（英語版） - `references/poc-scripts.md` — JavaScript / Python / cURL の PoC 設計と 5 原則 - `references/quality-pollution.md` — スキャナ垂れ流し・AI 生成丸投げの検出指標と対処、HackerOne 公式ポリシー、Hai Triage - `references/triage-process.md` — レポート状態（Accepted / Informative / Duplicate / OOS / N/A / Spam / Undecided）の判定基準と状態予測マトリクス、Intigriti 禁止行為一覧