report-writing

レポートの書き方

影響を最初に。人間味のある文体で。理論的な表現は避けてください。トリアージ担当者も人間です。

---

最も重要なルール

「could potentially」「could be used to」「may allow」は絶対に使わないでください。 実際にできるか、できないかのどちらかです。証明できていないなら、主張しないでください。

BAD:  "This vulnerability could potentially allow an attacker to access user data."
GOOD: "An attacker can access any user's order history by changing the user_id
       parameter to the target user's ID. I confirmed this using two test accounts:
       [email protected] (ID 123) successfully retrieved [email protected] (ID 456)
       orders, including their shipping address and payment method last 4 digits."

---

タイトルの形式

[Bug Class] in [Exact Endpoint/Feature] allows [attacker role] to [impact] [victim scope]

良いタイトル（具体的で、影響を最初に示している）：

IDOR in /api/v2/invoices/{id} allows authenticated user to read any customer's invoice data
Missing auth on POST /api/admin/users allows unauthenticated attacker to create admin accounts
Stored XSS in profile bio field executes in admin panel — allows privilege escalation
SSRF via image import URL parameter reaches AWS EC2 metadata service
Race condition in coupon redemption allows same code to be used unlimited times

悪いタイトル（曖昧で、トリアージ担当者の役に立たない）：

IDOR vulnerability found
Broken access control
XSS in user input
Security issue in API
Unauthorized access to user data

---

HACKERONE レポートテンプレート

## Summary

[One paragraph: what the bug is, where it is, what an attacker can do. Be specific.
Include: endpoint, method, parameter, data exposed, required access level.]

Example: "The `/api/users/{user_id}/orders` endpoint does not verify that the
authenticated user owns the requested user_id. An attacker can enumerate any
user's order history, including PII (email, address, phone) and purchase history,
by incrementing the user_id parameter. No privileges beyond a standard free
account are required."

## Vulnerability Details

**Vulnerability Type:** IDOR / Broken Object Level Authorization
**CVSS 3.1 Score:** 6.5 (Medium) — AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
**Affected Endpoint:** GET /api/users/{user_id}/orders

## Steps to Reproduce

**Environment:**
- Attacker account: [email protected], user_id = 123
- Victim account: [email protected], user_id = 456
- Target: https://target.com

**Steps:**

1. Log in as [email protected], obtain Bearer token

2. Send the following request:

GET /api/users/456/orders HTTP/1.1 Host: target.com Authorization: Bearer ATTACKER_TOKEN_HERE

3. Observe response:

```json
{
  "orders": [
    {"id": 789, "items": [...], "email": "[email protected]", "address": "123 Main St..."}
  ]
}

別のユーザーからのリクエストにもかかわらず、レスポンスには被害者のすべての注文履歴と個人識別情報（PII）が含まれています。

影響

認証済みの攻撃者は、user_id の値を順に変えることで、すべてのユーザーの注文を列挙できます。 これにより、氏名、メールアドレス、配送先住所、購入履歴、支払い方法（下4桁）が漏えいします。 約10万人のユーザーがいる場合、登録ユーザー全員に影響する大規模な個人識別情報（PII）の漏えいとなります。悪用に必要なのは無料アカウントのみで、簡単なループを使えば数分で実行できます。

推奨する修正

サーバー側で所有者を検証してください。

if order.user_id != current_user.id:
    raise Forbidden()

補足資料

[攻撃者のセッションから被害者の注文データが返されていることを示すスクリーンショット] [可能であれば、手順を解説する動画]

---

## BUGCROWD REPORT TEMPLATE

```markdown
# [IDOR] User order history accessible without authorization via /api/users/{id}/orders

**VRT Category:** Broken Access Control > IDOR > P2

## Description

[Same impact-first paragraph as HackerOne summary]

## Steps to Reproduce

[Same structured steps — exact HTTP requests, exact responses]

## Proof of Concept

[Screenshot/video showing the actual impact]

## Expected vs Actual Behavior

**Expected:** 403 Forbidden when user_id does not match authenticated user
**Actual:** 200 OK with victim's full order data

## Severity Justification

P2 (High) — Direct read access to other users' PII. Affects all user accounts.
No user interaction required. Exploitable by any authenticated user.
Automated enumeration could exfil all [N] user records in minutes.

## Remediation

Add ownership verification: `if order.user_id != current_user.id: raise 403`

---

INTIGRITI レポートテンプレート

# [Bug Class]: [Exact Impact] in [Endpoint/Feature]

## Description

[Impact-first paragraph. Start with what an attacker can do, not with how you found it.
Include: endpoint, method, parameter, data exposed, required privileges.]

## Steps to Reproduce

**Environment:**
- Attacker: [email protected] (standard account, no special role)
- Victim: [email protected]
- Tested: [date]

**Reproduction steps:**

1. [Login as attacker / visit URL / send request]

2. Send the following HTTP request:

\```http
METHOD /endpoint HTTP/1.1
Host: target.com
Authorization: Bearer ATTACKER_TOKEN
Content-Type: application/json

{"param": "victim_id_here"}
\```

3. Observe response contains victim's private data:

\```json
{"email": "[email protected]", "address": "123 Main St", ...}
\```

## Impact

[Specific, quantified impact. What data, how many users, what can attacker do.]

CVSS 3.1 Score: X.X ([Severity]) — AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

## Remediation

[1-3 sentence concrete fix. Include code if helpful.]

## Attachments

[Screenshot or Loom video showing the impact — Intigriti triagers prefer video for complex bugs]

Intigriti 固有の注意事項：

• タイトル形式：[Bug Class]: [One-line impact]（決まった形式は必要ありませんが、具体的にしてください）
• 深刻度は自分で設定します：Critical／High／Medium／Low／Exceptional
• 標準は CVSS 3.1 です（新しいプログラムでは CVSS 4.0 も受け付けています）
• スクリーンショットだけよりも PoC 動画が高く評価されます。Loom で録画してください
• セーフハーバー：Intigriti はこれを適用しているため、やや積極的なテストも安心して行えます

---

IMMUNEFI レポートテンプレート

# [Bug Class] — [Protocol Name] — [Severity]

## Summary

[One paragraph with: root cause, affected function, economic impact, attack cost.
Include numbers where possible: "attacker can drain $X in Y transactions."]

## Vulnerability Details

**Contract:** `VulnerableContract.sol`
**Function:** `claimRedemption()`
**Bug Class:** Accounting State Desynchronization
**Severity:** Critical

### Root Cause

[Exact code snippet showing the vulnerable code with comments]

## Proof of Concept

```solidity
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
// Foundry PoC — run: forge test --match-test test_exploit -vvvv

contract ExploitTest is Test {
    // ... full working exploit
}

影響

[定量化：「攻撃者は TVL の X%（現在のレートで $Y）を引き出せます。 必要なガス代は $Z です。攻撃は繰り返し実行できます。」]

推奨する修正

[変更前／変更後を示した具体的なコード変更]

---

## CVSS 3.1 QUICK SCORING

### Formula

CVSS = f(AV, AC, PR, UI, S, C, I, A)

### Metric Quick Picks

| Metric | Value | Weight | When |
|---|---|---|---|
| **Attack Vector (AV)** | Network | +0.85 | Via internet |
| | Local | +0.55 | Local access needed |
| **Attack Complexity (AC)** | Low | +0.77 | Repeatable |
| | High | +0.44 | Race/timing needed |
| **Privileges Required (PR)** | None | +0.85 | No login |
| | Low | +0.62 | Regular user account |
| | High | +0.27 | Admin account |
| **User Interaction (UI)** | None | +0.85 | No victim action |
| | Required | +0.62 | Victim must click |
| **Scope (S)** | Changed | higher | Affects browser/OS/other |
| | Unchanged | lower | Stays in app |
| **Confidentiality (C)** | High | +0.56 | All data exposed |
| | Low | +0.22 | Limited data |
| **Integrity (I)** | High | +0.56 | Can modify any data |
| **Availability (A)** | High | +0.56 | Crashes service |

### Typical Scores by Bug Class

| Bug | Typical CVSS | Severity |
|---|---|---|
| IDOR (read PII) | 6.5 | Medium |
| IDOR (write/delete) | 7.5 | High |
| Auth bypass → admin | 9.8 | Critical |
| Stored XSS (any user) | 5.4–8.8 | Med–High |
| SQLi (data exfil) | 8.6 | High |
| SSRF (cloud metadata) | 9.1 | Critical |
| Race condition (double spend) | 7.5 | High |
| GraphQL auth bypass | 8.7 | High |
| JWT none algorithm | 9.1 | Critical |

---

## SEVERITY DECISION GUIDE

### Critical (P1)
- Full account takeover of any user without interaction
- Remote code execution
- SQLi with ability to dump/modify entire DB
- Auth bypass to admin panel
- SSRF to cloud metadata → IAM credentials exfil

### High (P2)
- Mass PII exposure (email, phone, SSN, payment data)
- Privilege escalation from user to admin
- SSRF reaching internal services (data returned)
- Stored XSS executing for all users of sensitive feature
- Payment bypass / financial loss without limit

### Medium (P3)
- IDOR on specific user's non-critical data
- XSS on low-sensitivity page requiring victim interaction
- CSRF on important but non-critical action
- Rate limit bypass on OTP (with effort demonstrated)

### Low (P4)
- Information disclosure (non-sensitive, no PII)
- Clickjacking on sensitive action WITH working PoC
- CORS on limited data

---

## SEVERITY SELF-ASSESSMENT

Each YES raises severity:

1. 他のユーザーの個人情報／健康情報／金融情報が漏えいするか？ → 深刻度 +1
2. アカウント乗っ取りや権限昇格が可能か？ → 深刻度 +2
3. 被害者側の操作がまったく不要か？ → 深刻度 +1
4. 特定の条件に限らず、すべてのユーザーに影響するか？ → 深刻度 +1
5. 内部ネットワークへのアクセスなしでリモートから悪用できるか？ → High+ の基本条件

---

## DOWNGRADE COUNTERS

| Program Says | Counter With |
|---|---|
| "Requires authentication" | "Attacker needs only a free account — no special role or permission" |
| "Limited impact" | "Affects [N] users / exposes [PII type] / $[amount] at risk" |
| "Already known" | "Show me the report number — I searched hacktivity and found none" |
| "By design" | "Show me the documentation stating this is intended behavior" |
| "Low CVSS" | "CVSS doesn't capture business impact — attacker can extract [X] in [Y] minutes" |
| "Not exploitable" | "Here is the exact response showing victim's data returned to attacker session" |

---

## THE 60-SECOND PRE-SUBMIT CHECKLIST

[ ] タイトルが次の形式に従っている：[Class] in [endpoint] allows [actor] to [impact] [ ] 最初の文で、正確な影響を平易な英語で説明している [ ] 再現手順に、コピーしてすぐ使える正確な HTTP リクエストが含まれている [ ] バグを示すレスポンスが含まれている（スクリーンショットまたは JSON 本文） [ ] 2つのテストアカウントを使用している。1つのアカウントを使った自己テストだけではない [ ] CVSS スコアを算出して記載している [ ] 推奨する修正が1～2文で書かれている（長々とした説明ではない） [ ] エンドポイントのパスやパラメーター名に誤記がない [ ] レポートが600語未満である。トリアージ担当者は長いレポートを流し読みします [ ] 主張した深刻度が説明した影響と一致している。誇張しない [ ] 「could potentially」や「may allow」を使っていない [ ] トリアージ担当者が初期状態から再現できる PoC になっている

---

## CVSS 4.0 QUICK REFERENCE (newer programs)

CVSS 4.0 replaced CVSS 3.1 in November 2023. Some newer programs require it.

### Key Differences from CVSS 3.1

| Metric | CVSS 3.1 | CVSS 4.0 |
|---|---|---|
| Attack Vector | Network/Adjacent/Local/Physical | Same |
| Attack Complexity | Low/High | Low/High |
| **NEW**: Attack Requirements | (didn't exist) | None/Present (replaces some PR/UI) |
| Privileges Required | None/Low/High | Same |
| User Interaction | None/Required | None/Passive/Active |
| Scope | Unchanged/Changed | REMOVED |
| **NEW**: Sub-Impact metrics | (didn't exist) | Vulnerable/Subsequent system impact |

### CVSS 4.0 Score Examples

| Finding | CVSS 4.0 Score | Vector |
|---|---|---|
| Unauthenticated RCE | 10.0 | CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H |
| IDOR read PII, auth required | 6.9 | CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N |
| Stored XSS, admin views it | 8.2 | CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:P/VC:H/VI:H/VA:N/SC:H/SI:H/SA:N |
| SSRF → cloud metadata | 8.7 | CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:H/SI:H/SA:N |

### Quick CVSS 4.0 Calculator

使用先：https://www.first.org/cvss/calculator/4.0 主なフィールド： VC/VI/VA = 脆弱なシステムの機密性／完全性／可用性 SC/SI/SA = 影響を受ける後続システム（下流への影響） AT = None（特別な条件なし）| Present（競合状態／特定の設定が必要） UI = None | Passive（被害者が URL にアクセスする）| Active（被害者が明示的な操作を行う）

**Practical rule**: If program uses CVSS 4.0 and you don't know the vector, use the calculator and include the full string starting with `CVSS:4.0/AV:...`. Programs cannot dispute a valid vector string.

---

## HUMAN TONE GUIDELINES

**Write to a person, not a system:**
- Triagers are tired. Get to the impact in sentence 1.
- Use "I" not "the researcher" — you found it, own it
- Short paragraphs, bullet points for steps
- Hyperlink relevant docs if needed

**Escalation language (when payout is being downgraded):**

「この脆弱性の悪用に特別な権限は必要ありません。無料アカウントだけで実行できます。」 「漏えいするデータには[PII の種類]が含まれており、GDPR の要件の対象です。」 「攻撃者は簡単なループで自動化でき、数分ですべての[N]件のレコードを取得できます。」 「内部システムへのネットワークアクセスなしで、外部から悪用できます。」 「影響は、[機能／データの種類]の完全なデータ漏えいに相当します。」

**Avoid:**
- Jargon the triager might not know
- 5-paragraph explanations of what IDOR is (they know)
- Theoretical chains ("could be combined with X to...")
- Passive voice ("it was observed that...")
- Qualifying language ("seems to," "appears to")

---

## STEPS TO REPRODUCE FORMAT (triager-optimized)

```markdown
**Setup:**
- Account A (attacker): [email protected], ID=111
- Account B (victim): [email protected], ID=222
- Both created via normal registration — no special access

**Steps:**

1. Log in as Account A
2. Send this request (replace `111` with victim ID `222`):

\```
GET /api/v2/resource/222 HTTP/1.1
Host: target.com
Authorization: Bearer ACCOUNT_A_TOKEN
\```

3. Response contains Account B's private data:

\```json
{"id": 222, "email": "[email protected]", "name": "Victim User", "address": "..."}
\```

**Expected:** 403 Forbidden
**Actual:** 200 OK with victim's private data

---

検証

1. 人間らしい文体のチェック — AI特有の語句が検出されることを確認します。

   grep -q "comprehensive\|leverage\|seamless\|ensure\|delve" SKILL.md && echo "FAIL: AI-signal words present" || echo "PASS: no AI-signal words"
   

2. タイトルの形式 — タイトルの形式が記載されていることを確認します。

   grep -q "Bug Class.*in.*Endpoint.*allows.*attacker" SKILL.md && echo "PASS: title formula present" || echo "FAIL"
   

すべてのテストで、レポートを作成できる状態かを検証します。

---

注意点

• エグゼクティブサマリーを後回しにする — 経営幹部が読むのはこのセクションだけです。技術的な詳細ではなく、ビジネスへの影響から始めます。
• 「可能性がある」「かもしれない」という表現 — こうした言葉は、理論上の発見であることを示します。「攻撃者が〜できる」と「実証済み」を使います。
• 再現手順がない — 実際にリクエストを発生させる正確な HTTP リクエストがなければ、「/search で XSS を見つけた」という報告には価値がありません。
• CVSS と影響度の不一致 — 深刻度を「重大」と主張しながら、影響度を「低」と説明すると、信頼性が損なわれます。CVSS スコアは、実証された影響度と一致させる必要があります。
• 長すぎるレポート — トリアージ担当者はレポートにざっと目を通します。本文は 600 語未満にします。詳細な証拠には添付ファイルを使います。
• AI らしい表現 — 「包括的」「活用する」「シームレス」「確実にする」といった言葉は、AI が生成した文章を思わせます。率直で、人間らしい表現を使います。

---

関連スキルと連携

• triage-validation — そもそもレポートを書くべきか判断するときに使います。ワークフローの基本原則：triage-validation の 7 問ゲートを通過する前に、このスキルを絶対に開かないでください。ゲートを通過できない発見は、レポートにまとめず、破棄する必要があります。
• bugcrowd-reporting — 対象が Bugcrowd プログラムの場合に使います。ワークフローの基本原則：このスキルの本文テンプレートを土台とし、bugcrowd-reporting が VRT の選定、深刻度を求める段落、OOS 条項への反論を重ねます。
• evidence-hygiene — PoC のスクリーンショットや HAR をレポートに添付するときに使います。ワークフローの基本原則：「Supporting Materials」／「Proof of Concept」セクションで参照するすべての成果物は、添付前に evidence-hygiene を通して、Cookie と PII をマスキングします。
• redteam-report-template — エンゲージメントが外部レッドチーム（バグバウンティではない）の場合に使います。ワークフローの基本原則：bb-methodology の PART 0 でエンゲージメントの種類を確認します。レッドチームの場合は、このスキルを redteam-report-template に切り替えます（対象読者と構成が異なります：Subject／Observations／Description／Impact／Recommendation／PoC）。

---

オペレーター向けメモ

提供元の基盤に、実際のエンゲージメントから得た知見を追加したものです。実際に許可を得て実施したエンゲージメントと、このリポジトリの 31 以上のスキル領域にわたるライブテストを対象にしたフェーズ 2 の検証から得られた知見です。上流の方法論が WHAT（何をするか）を扱うのに対し、このレイヤーでは WHEN-IT-ACTUALLY-WORKS（実際にうまくいく条件）と FAILURE-MODES（失敗パターン）を扱います。

実際に使うタイトルの形式

<asset> | <bug class> | <impact> — 3 つの要素だけを使い、余計な言葉は入れません。トリアージ担当者はタイトルに目を通すのにおよそ 3 秒しかかけず、それを基にキューの順序を決めます。

• 悪い例：「/api/users で興味深い発見」
• 悪い例：「API の IDOR 脆弱性」
• 良い例：「認証済み IDOR により /api/users/{uid} の管理者メールアドレスとロールが漏えい」
• 良い例：「未認証の SSRF により /preview?url= から AWS メタデータ [REDACTED_IP] にアクセス可能」

悪いタイトルのレポートは、最後に開かれます。良いタイトルのレポートは、最初に開かれます。同じ発見でも、キュー内の位置、トリアージ日、報奨金の支払い速度が変わります。

トリアージ担当者が実際に読むもの

新しいレポートを読む順序は次のとおりです。

1. タイトル（3 秒）
2. 影響またはサマリーの最初の段落（15 秒）
3. curl コマンドまたは HTTP リクエストのブロック（30 秒）
4. 再現手順（最初の 3 項目で納得できた場合のみ）
5. その他すべて（フォローアップレビューの場合のみ）

レポートの冒頭を徹底的に最適化します。説明は中盤に置きます。手順 3 までに納得したトリアージ担当者は、残りをそのまま承認します。手順 3 までに納得できなかった担当者は、手順 5 を読みません。

CVSS 3.1 vs Bugcrowd VRT vs H1 のデフォルト重大度

この3つのシステムは、約30％の割合で評価が食い違います。最もよくある差異は、CVSS 7.x（High）の指摘が、Bugcrowd P4（Low）またはH1のデフォルトMediumに相当するケースです。プラットフォームのデフォルト評価がCVSSより低い場合：

1. 重大度リクエストの段落を、本文の最初のセクションとして記載してください。 Bugcrowdではこれが尊重されます。（標準テンプレートについては、bugcrowd-reportingを参照してください。）
2. 感情ではなく、CVSSベクター文字列とビジネスへの影響を根拠にリクエストしてください。 「CVSS 3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N = 7.5 High。テナントをまたぐデータ漏えいには機密性：高が該当するためです。」
3. 指摘に該当する、プラットフォーム独自のVRTエントリーを引用してください。 プラットフォームに異議を唱えるのではなく、その枠組みの中で申請してください。

認可を受けたバグバウンティの取り組みで、デフォルトがP4だった指摘が、重大度リクエストの段落によってP3に引き上げられた事例があります。引き上げは自動ではありません。根拠に基づいて、本文の最初のセクションで申請する必要があります。

エビデンスのローテーション

提出本文に記載された内容は、すべてプラットフォームに永久に記録されます。それを踏まえて行動してください。

• 取り組み専用に作成した使い捨てのテストアカウントを使用してください。
• 提出のたびにCookie／トークンをローテーションしてください（レポートに貼り付けたCookieを再利用しないでください）。
• 本番環境のCookie、実ユーザーのメールアドレス、実際の個人情報をレポート本文に貼り付けないでください。PoCの手順では伏せ字にしてください。
• 管理パネルのスクリーンショットでは、ユーザー一覧をぼかし、URLバーにトークンが含まれている場合はURLバーもぼかしてください。

完全な取得・伏せ字化の手順については、evidence-hygieneを相互参照してください。

スキルと公開ドキュメントにおけるデータ衛生

スキル、READMEファイル、および一般公開されるあらゆるドキュメントは、完全に固有情報を含まないものにしてください。以下は絶対に含めないでください。

• 企業名、ドメイン名、ブランド名
• 従業員の氏名、メールアドレス、個人を特定できる情報
• 特定可能なターゲットに結び付く具体的な脆弱性の詳細
• プロジェクトID、バケット名、内部ホスト名

代わりに、固有情報を含まないパターンを使用してください。

BAD:  "customer.example had PHPInfo + XMLRPC -> RCE"
GOOD: "e-commerce target had PHPInfo + XMLRPC -> RCE"

BAD:  "[email protected] exposed via REST API"
GOOD: "corporate email pattern exposed via REST API"

BAD:  "customer.example MySQL 3306 OPEN"
GOOD: "healthcare SaaS target had MySQL 3306 exposed"

ターゲットごとの詳細な指摘は、オペレーターが選択した OUTPUT_DIR配下に保存します。スキルには取り組みのエビデンスではなく、 パターン、テクニック、方法論を記載します。

スキルまたはREADMEを作成するとき：

• TARGET、example.com、evil.comをプレースホルダーとして使用してください。
• セクター単位の説明（例：「ヘルスケアSaaS」、「Eコマース」、「政府機関ポータル」）を使用してください。
• ターゲットごとの具体例ではなく、集計統計（例：「WPサイトの約7～8％にCORSがある」）を使用してください。
• 実例が不可欠な場合は、特定につながる情報をすべて取り除いてください。ドメインをセクター名に置き換え、メールアドレスを削除し、プロジェクトIDを匿名化してください。

プラットフォーム別テンプレート — 違いがある場合

プラットフォーム	文体	必須の構成	重大度の決定方法
HackerOne	説明形式	概要 -> 手順 -> 影響 -> 推奨修正	トリアージ担当者が設定、異議申し立て可能
Bugcrowd	構造化形式	重大度リクエスト -> VRTカテゴリ -> タイトル -> 本文 -> 修正方法	VRTのデフォルト値 + 手動での上書きを求める段落
Intigriti	中間的	概要 -> PoC -> 影響 -> 推奨事項	研究者が提案、トリアージ担当者が確認
Immunefi	PoC優先	動作するPoCコード -> 手順の説明 -> 影響 -> 重大度	Foundry/Hardhatコードが主要な提出物

誤ったテンプレートの文体を選ぶと、有効性が損なわれます。説明が多すぎるBugcrowdレポートでは、トリアージ担当者が必要とするVRTとの対応付けが欠けてしまいます。一方、構造化されたH1レポートは簡潔すぎる印象になり、追加質問が発生して報奨金の支払いが遅れる原因になります。

レポート作成における最大のミス

実証せずに、攻撃が「理論上」可能だとか、「より大きな影響につながる可能性がある」と主張することです。トリアージ検証のQ6（技術的に可能な範囲を超える影響）は検証段階でこうした報告を退けるため、レポート作成でも同じ基準を適用する必要があります。

有効な方法は2つあります。

1. 影響を最初から最後まで具体的に示します。 テストアカウントで一連の動作を記録します。リクエストとレスポンスの全シーケンスを貼り付けます。これで完了です。
2. 実際に実証した内容に合わせて、重大度の主張を引き下げます。 「メールアドレスとロールを読み取る/api/users/{uid}のIDOR」は実在し、報告可能です。「管理者権限の奪取につながる可能性があるIDOR」は、奪取を実証するまでは報告できません。

どちらかを選んでください。「可能性がある」や「許す可能性がある」といった表現で中間を取ってはいけません。こうした表現は、報告が理論上のものだとトリアージ担当者に伝えるサインであり、理論上の報告はN/Aになります。

• bb-methodology — Phase 5のレポート作成ステップを開始するときに使用します。ワークフローのプリミティブです。Phase 5が/reportを呼び出し、プラットフォーム固有のテンプレート（H1 / Bugcrowd / Intigriti / Immunefi）を読み込むスキルです。