bugcrowd-reporting

BUGCROWD の報告 — プログラム固有の戦術

汎用の report-writing スキルを補完するものです。VRT マッピング、OOS 条項への反論、またはプログラムごとの対象選定が重要となる、Bugcrowd への報告で使用してください。

このスキルでは、Bugcrowd の報告フローに特化したパターンを解説します。各プラットフォームに共通する汎用テンプレート（HackerOne / Bugcrowd / Intigriti / Immunefi の報告本文）については、report-writing スキルを使用してください。報告するかどうかを決める前に実施する 7-Question Gate については、triage-validation を使用してください。

---

1. VRT カテゴリーの選択 — 検索とフォールバックの戦略

Bugcrowd の報告フォームでは、VRT（脆弱性評価分類）の選択が 1 つ必要です。ドロップダウンのデフォルトの深刻度は、選択したノードに紐付けられています。選択を誤ると、実際の影響が P3 または P2 であるにもかかわらず、フォームがより低い優先度（多くの場合 P4）を自動的に提示します。

注：VRT のデフォルトの深刻度は固定値ではありません。Bugcrowd はバージョンごとに VRT スキーマを改訂しており、各プログラムが独自の優先度設定によってデフォルトを再マッピングする場合もあります。以下の例に示す P 値（例：「No Rate Limiting on Form → Login」のデフォルトは P4）は、執筆時点での一般的な基準値です。この値を前提にせず、必ず対象プログラムの現在のフォームで実際に自動提示される深刻度を確認してください。

1.1 検索の優先順位（以下の順に試し、バグを正確に表すものの中から最も深刻度の高いものを選択してください）

どの発見事項でも、VRT ドロップダウンを次の語句で順に検索してください。

1. バグの主要な分類 — 例：IDOR、XSS、SSRF、auth bypass、2FA bypass
2. 露出したデータのカテゴリー — 例：PII、sensitive data exposure、disclosure of secrets
3. 回避された制御 — 例：broken access control、authentication bypass
4. エンドポイントの種類 — 例：no rate limiting on form > login、no rate limiting on form > change password
5. 汎用の親ノード — 例：Server Security Misconfiguration > Other、Broken Access Control > Other

1.2 バグを正確に表すものの中から、最も深刻度の高いものを選択してください

デフォルトの深刻度を上げるためだけに、バグを誤って表す VRT を選択してはいけません。トリアージ担当者が再割り当てを行い、誤った分類を問題視する可能性があります。最も具体的で、かつ正確な VRT を選択し、デフォルトの深刻度が適切でない場合は §2（深刻度の手動オーバーライド）を使用してください。

1.3 把握しておくと便利な一般的なマッピング

発見事項の種類	第一候補の VRT	フォールバック
パスワード変更時に 2FA がないことによる ATO	Broken Authentication & Session Management → Second Factor Authentication (2FA/MFA) → Bypass	Broken Auth → Authentication Bypass → Other
レート制限のないパスワードオラクル	Broken Authentication & Session Management → Authentication Bypass → Other	Server Security Misconfiguration → No Rate Limiting on Form → Login
GraphQL のイントロスペクション / APQ の許可リスト回避	Server Security Misconfiguration → Other（本文で根拠を説明）	Broken Access Control → Other
ユーザー名から実名の PII を列挙可能	Sensitive Data Exposure → PII Leakage / Disclosure of Secrets → Non-Corporate User	Broken Access Control → Other
セキュリティ上重要な操作での状態の不整合	Application-Level DoS → Other（状態の不整合として説明）	Server Security Misconfiguration → Other
認証フローのエンドポイントに対するメール/SMS の大量送信	Server Security Misconfiguration → No Rate Limiting on Form → Email-Triggering / SMS-Triggering	Server Security Misconfiguration → No Rate Limiting on Action
トークンのブルートフォース（メール変更 OTP、パスワードリセット）	Broken Authentication → Authentication Bypass → Other	Server Security Misconfiguration → No Rate Limiting on Action

1.4 適切な VRT がない場合

Server Security Misconfiguration → Other または Broken Access Control → Other を選択し、説明本文の冒頭に「VRT mapping note」を記載してください。選択したノードが最も近い選択肢である理由と、実際のバグの内容を説明します。

---

2. 深刻度の手動指定

Bugcrowd のフォームでは、VRT のデフォルトとは別に技術的な深刻度を手動で設定できます。フォームの説明にも、次のように記載されています。「VRT が推奨する深刻度が、提出内容に適用される深刻度になるとは限りません。」

2.1 手動指定する場合

次の場合は、VRT のデフォルトを上書きしてください。

• 複数の脆弱性を連鎖させた結果が、単独のバグクラスより高い深刻度になる場合（連鎖 → ATO）
• VRT のカテゴリーが近似的なもので、デフォルトの深刻度が実際の影響クラスを反映していない場合
• プログラム独自の Focus Areas に、この結果が VRT のデフォルトより高い深刻度で明記されている場合
• 漏えいするデータの種類が、VRT の例で使われているものより機微な場合（例：ハンドルの列挙ではなく、実名を含む PII）

2.2 手動で指定する方法（フォームの操作）

1. バグを最も正確に表す VRT を選択します（§1 に従ってください）
2. 自動提案された深刻度（P4、P3 など）を確認します
3. Technical Severity フィールドで、申請する深刻度を手動で選択します
4. 説明本文の最初のセクションに、Severity Request の段落を追加します（§3 に従ってください）

2.3 過大な主張は避ける

P1 を過剰に主張するのは、トリアージ担当者の信頼を失う最も手っ取り早い方法です。P1 は、ユーザー操作なしの ATO、RCE、大量の PII の持ち出し、資金の窃取など、重大度が Critical に分類される影響に限定してください。P1 につながる連鎖に、別途盗まれた Cookie があるという前提が必要な場合は、単独のプリミティブを P3 として報告し、相互参照を付けて連鎖について明示的に説明してください（§4 に従ってください）。

---

3. 深刻度申請の段落 — 本文の先頭に必ず記載

VRT のデフォルトの深刻度が影響を低く評価している場合、説明本文の最初のセクションには、深刻度申請の段落を記載してください。トリアージ担当者が最初に読む内容であり、フォームに「P4」と表示されているのを見て自動的に却下されることを防げます。

3.1 テンプレート

## Severity request — please review carefully before applying VRT default

The closest VRT category for this finding is "[chosen VRT]," which Bugcrowd defaults to **P[N] ($X-$Y in [program]'s rubric)**. **I am requesting evaluation at P[M] [standalone | in chain with submission XXXX]** for the following reasons:

1. **[Impact axis 1]** — [specific reason this finding exceeds the VRT default's example]
2. **[Impact axis 2]** — [specific reason, often citing the program's own Focus Areas]
3. **[Impact axis 3]** — [specific reason, often comparing to historical bounty payouts for the same data class]

[Optional: one paragraph contrasting the VRT default's typical example with this finding's actual impact, e.g., "P4 = No Rate Limiting on Login Form" applies to ordinary login pages where brute force is bounded by lockout policies; this endpoint has neither lockout nor throttle.]

3.2 記入例のパターン

## Severity request — please review carefully before applying VRT default

The closest VRT category for this finding is "No Rate Limiting on Form → Login," which Bugcrowd defaults to **P4 ($XX–$YY in this program's rubric)**. **I am requesting evaluation at P3 standalone, P2 in chain with submission XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX** for the following reasons:

1. **[Endpoint] is a password-disclosure oracle, not a generic rate-limit gap.** The endpoint returns true/false for a supplied password — combined with cookie theft, it is the exact primitive an attacker uses to learn the victim's *durable* credential from a stolen *transient* session.
2. **The chained outcome is "Account Takeover,"** explicitly listed under the program → Focus Areas → Critical (P1) examples. This finding is one of two independent links that make that chain work; the other is submission XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX.
3. **The two findings have independent fix surfaces.** Per the program's "one fix = one bounty" rule they should be evaluated as two separate findings whose chain raises the joint severity.

The "P4 = No Rate Limiting on Login Form" default applies to ordinary login pages where brute-force is bounded by lockout policies. This endpoint has neither lockout nor throttle, and the result of brute force is the *user's actual password* (not a session) — making the impact significantly higher than the default VRT severity assumes.

3.3 トーンのガイドライン

• 「深刻度の申請 — VRT のデフォルトを適用する前に、慎重にご確認ください」（この文言をそのまま使用してください）で始めてください。トリアージ担当者はこの表現を認識しており、自動的に却下しません。
• 太字は控えめに使用し、理由ごとに多くても1〜2箇所にしてください。
• 「potentially（潜在的に）」や「may allow（可能にする場合があります）」は使わないでください。これらは深刻度を下げる口実になります。
• プログラム独自の Focus Areas／受け入れ対象の影響リストを、正確な名称で引用してください。
• 関連する提出内容を相互参照する場合は、提出 ID を省略せず UUID 形式で記載してください。

---

4. OOS 条項への反論 — テンプレート

Bugcrowd のトリアージ担当者は、報告書を読まずに OOS 条項に当てはめ、調査結果を自動的に却下することがあります。これを防ぐため、OOS 条項を引用し、調査結果が該当しない理由を説明する In-scope justification セクションを含めてください。

4.1 「認証以外のエンドポイントにおけるレート制限」への反論

認証エンドポイント（ログイン、パスワード変更、パスワード検証、OTP 検証、トークン検証）に関する調査結果の場合：

## In-scope justification

The program OOS list excludes "Rate limiting or brute-force issues on **non-authentication** endpoints." `[endpoint name]` is the canonical authentication endpoint — it accepts a password/token/OTP and returns whether it matches the user's stored credential. By definition this is an authentication primitive. The OOS clause's "non-authentication" qualifier therefore does NOT apply.

4.2 「デバッグ情報の開示」への反論（スキーマ／イントロスペクションに関する調査結果向け）

スキーマの開示が実際には制御の回避にあたる場合（例：GraphQL の許可リストを回避して、ミューテーションの対象範囲を公開する場合）：

## In-scope justification

This is not a "debug information" finding. The [persisted-query allowlist | introspection gate | etc.] is acting as an authorization control on the [GraphQL surface | API tree | etc.]. The bypass converts that gate into a no-op — multiple [mutations | endpoints] become reachable that the official clients cannot invoke. The schema disclosure is incidental; the impact is **mutation-surface unlock**, not information leakage.

4.3 「リスクの低い情報によるユーザー列挙」への反論

「このハンドル／メールアドレスが存在する」という情報以上のものが漏えいする場合：

## In-scope justification

The program OOS list excludes "User Enumeration issues with **low-risk and insignificant** information being enumerated." The data leaked here is **neither low-risk nor insignificant**: it includes the matched user's [full real first name, last name, profile photo / SSN last 4 / phone number / etc.]. Real-[name | identity | etc.] knowledge is the same data class that gates the program's own [account-recovery flows / fraud-investigation interviews / support-call verification], which means this lookup directly defeats one of the program's own anti-fraud controls. This is PII disclosure, not handle enumeration.

4.4 「理論上の問題／悪用不可能」への反論

調査結果の悪用可能性を、エンドツーエンドで実証できている場合：

## In-scope justification

This finding is exploitable end-to-end as demonstrated in the PoC: [one-sentence summary of the proven exploitation path]. The PoC includes [N HTTP requests with redacted cookies | N screenshots | a sanitized HAR file | etc.] showing the attacker's session [reading victim data | changing victim credentials | etc.]. The OOS clause for "theoretical issues that are not exploitable, or can not be demonstrated as exploitable" does not apply.

4.5 エンドツーエンドの証明がない場合

完全な悪用経路を実証できておらず、「API の挙動」に関する観察しかない場合、その調査結果は理論上のものです。報告しないでください。不足している証拠（配信確認、トークン形式の調査、レスポンス内の別アカウントの被害者データなど）を記録し、再評価してください。理論上の調査結果を報告すると、プラットフォーム上での研究者としての評判を損ないます。

5. 連鎖した発見事項 — 相互参照の戦略

影響度の高い発見事項の多くは、2つ以上の独立したプリミティブを連鎖させたものです（オラクル + ステップアップ認証の欠如 = ATO）。Bugcrowd のプログラムルールでは、次のように定められています。「1つの報告につき、1つの脆弱性を提出してください。影響を示すために複数の脆弱性を連鎖させる必要がある場合は、まとめて提出してもかまいませんが、連鎖の内容を明確に説明してください。」

5.1 連鎖の提出戦略

1. 連鎖によって生じる最も深刻な結果を特定します（通常、プログラムの重点領域にある P1/P2 の例に該当するものです）。
2. 連鎖を構成するプリミティブを先に、それぞれ個別の報告として提出します — 各プリミティブ単独での深刻度（通常は P3/P4）で提出してください。提出の UUID は提出後にのみ発行されるため、参照先となるプリミティブを先に作成しておく必要があります。各プリミティブの本文には、ひとまずプレースホルダーとして相互参照行を残しておきます。
3. 連鎖を利用する報告を提出します — 本文で、連鎖による完全な ATO/RCE などの影響を連鎖後の深刻度（例：P1）で説明する報告です。プリミティブはすでに存在するため、利用側の報告にある「Chain partners」ブロックに実際の UUID を記入します（§5.2 を参照）。
4. 利用側の報告を提出した後で、各プリミティブを編集し、利用側の UUID を追記します：「Chain partner: submission [UUID] for the full impact narrative.」（参照は双方向なので、一方の報告を提出した後にもう一方を編集する必要があります — Bugcrowd では提出後に説明本文を編集できます。）

5.2 相互参照のテンプレート

連鎖を利用する報告の本文の冒頭付近に記載します。

## Chain partners (filed as separate reports)

- **submission [UUID-1]** — [primitive 1: e.g., `me.verify_password` no rate limit]
- **submission [UUID-2]** — [primitive 2: e.g., GraphQL APQ allowlist bypass]

These primitives have independent fix surfaces and are filed separately per the program's "one fix = one bounty" rule. The chained impact described here requires both primitives to be exploited end-to-end.

各プリミティブの本文に記載します。

## Chain context

This finding is the [N]th of [M] independent primitives that together produce [impact, e.g., "permanent account takeover from a stolen session cookie"]. The full chain narrative and the chained severity (P1) are documented in submission [UUID]. This standalone report is at P3 reflecting the primitive's individual impact.

5.3 してはいけないこと

• 連鎖全体の説明を、すべてのプリミティブの本文に貼り付けないでください。代わりに相互参照を使用します。
• 各プリミティブが単独で P1 に該当すると主張しないでください。過大な主張は、関連するすべての報告の信頼性を損ないます。
• 連鎖全体に対して単一の報奨金を求めないでください。プログラムの「修正1件につき報奨金1件」というルールでは、独立した修正対象ごとに別々の報奨金が支払われます。連鎖はマージリクエストではなく、深刻度を引き上げる要因として説明してください。

---

6. 対象の選択 — QA と本番環境

本番環境と QA の両方のアセットを対象範囲とするプログラム（例：app.target.com と app-qa.target.com）では、対象を慎重に選択する必要があります。

6.1 適切な対象のドロップダウン項目を選ぶ

テストした対象	選択する対象	理由
本番アプリ/API	本番環境の対象	最も正確です。実際のユーザーに影響が及んだことを示せます
QA アプリ/API（米国外の研究者に関するプログラムルールに従う場合）	QA の対象（例：Sign In - (QA)、Enrollment - (QA)）	プログラムルールに沿った正確な選択であり、善意のテスターであることを示せます
QA をテストしたが、該当する QA の対象がない場合	本文に QA に関する明確な免責事項を記載したうえで、最も近い本番環境の対象	必要に応じてトリアージ担当者が適切に再割り当てします
複数のアセットに影響する発見事項	バグの発生元、または影響が最も大きいアセット	影響を受ける他の対象を本文に列挙します

6.2 QA でテストした発見事項を提出する場合の QA 免責事項の段落

## Notes for triagers

- Tested in the QA environment ([qa-host]) per the program's instruction for non-US researchers / per the program's QA-testing scope.
- Production may enforce additional controls that QA does not — please confirm whether the same resolver code path runs on production.
- All testing limited to my own QA test account; no other accounts were interacted with.
- Selected target: `[chosen-target]`. Selected VRT: `[chosen-VRT]`. Both selected as closest available matches; please reassign if more appropriate options exist.

---

7. 研究者側での注意事項（Bugcrowd 固有）

これらは、報告本文そのものには含まれませんが、提出物の品質に影響するプログラムルールに関する項目です。

7.1 アカウントのメールアドレス — Bugcrowdninja エイリアス

Bugcrowd が管理するプログラムの多くでは、対象上のアカウントメールアドレスとして、研究者に @bugcrowdninja.com のエイリアスを使用するよう求めています。これにより、対象の不正対策チームに対し、トラフィックが善意のテスターによるものだと示されます。手順は次のとおりです。

1. Bugcrowd のエイリアス（[email protected] のような形式）を使って対象に登録します
2. すでにアカウントを持っている場合は、テストを始める前にメールアドレスをエイリアスに変更します
3. プログラムで複数アカウントを使ったテストの連絡窓口が用意されている場合は、そこを利用して、追加のエイリアス付きアカウント（[email protected] など）の使用を調整します
4. 報告の「Notes for triagers」セクションに使用したエイリアスを記載し、トリアージ担当者がログ内のテストトラフィックを照合できるようにします

7.2 PoC 後のアカウント状態の復元

状態を変更する操作（パスワードの変更、メールアドレスの変更、デバイスの削除、送金）を実証した後は、次の手順を実施してください。

1. 直ちにアカウントを PoC 前の状態に戻します（例：パスワードを元の値に戻します）
2. レポートに復元したことを記載します — 「PoC の直後にアカウント状態を復元しました。」
3. 復元が不可能な場合（例：送信したメールを取り消せない場合）は、残っている状態を正直に記載します

7.3 提出後の Cookie／セッションのローテーション

セッション Cookie に由来する証拠を含むレポートを提出した後は、次の手順を実施してください。

1. ログアウトして再度ログインし、セッション Cookie をローテーションします
2. 提出したスクリーンショット／HAR で確認できる Cookie の値は、すでに無効です
3. 必要に応じて、テストアカウントのパスワードを他では使っていない新しい値に変更します。これにより、PoC のスクリーンショットに表示されたパスワードも無効になります

7.4 テストアカウントがロックされた場合

1. ロックを回避するために 2 つ目のアカウントを作成しないでください。不正行為のように見えます
2. プログラム固有の連絡先が指定されている場合は、Bugcrowd のユーザー名とレポート ID を添えてメールで連絡します
3. プログラムチームによるロック解除を待ちます。ロック期間中のテストは信頼性を損ないます

---

8. 複数の発見事項がある案件での提出順序戦略

1 つの案件で複数の発見事項がある場合は、提出順序が重要です。

8.1 推奨される順序

1. 利用する発見事項より先に、チェーンのプリミティブを提出します。 利用する発見事項はプリミティブのレポート UUID を参照しますが、UUID はプリミティブを提出して初めて得られます（§5.1 を参照）。最も証拠が充実したプリミティブを最初に提出してタイムスタンプを確保し、その後、チェーンに含まれる残りのプリミティブを提出します。
2. 次に、チェーンを利用する発見事項を提出します — 実際のプリミティブ UUID を記入した後、各プリミティブを編集して利用する発見事項の UUID を追記します（Bugcrowd では提出後の本文編集が可能です）。
3. 次に、単独の P3 発見事項を提出します。 証拠の質に基づいて並べ、最も証拠が充実したものを最初に、OOS に近いリスクのある発見事項を後にします。
4. OOS リスクのある発見事項は最後に提出します。 これらを提出する頃には、この案件で信頼できる実績を築けています。

8.2 提出 ID の追跡

各提出の UUID、重大度、1 行の説明を記したシンプルなテキストファイルを用意します。これらの ID は、レポート間や、その後のトリアージ担当者とのやり取りで参照します。

8.3 避けるべきこと

• 数分のうちにすべての発見事項をまとめて提出しないでください。トリアージ担当者には、手間をかけずにスパムを送っているように見えます。
• 同じ案件のクリーンな P3 より先に、OOS リスクのある発見事項を提出しないでください。クリーンな発見事項が信頼性を築き、リスクのある発見事項もその文脈で読まれることで有利になります。
• プログラムから明示的に許可されるまで、発見事項を公開しないでください。Bugcrowd の守秘義務は、未解決の問題と解決済みの問題の両方に適用されます。

---

注意点

• 誤った VRT → 自動的な格下げ — バグに合わない VRT カテゴリを選ぶと、トリアージ担当者によって自動的に P4 へ格下げされます。検索の優先順位：正確なバグの種類 → 公開されたデータ → 回避された制御 → エンドポイントの種類 → 汎用的な親カテゴリ。
• VRT の誤った表現 — バグの内容を表していない高深刻度の VRT を選んで深刻度をつり上げると、発覚して信頼を損ないます。最も具体的で正確な VRT を選び、その後に深刻度の引き上げを求める段落を使ってください。
• 深刻度の引き上げ要求が本文の途中にある — 深刻度の引き上げを求める段落が最初のセクションにない場合、トリアージ担当者は VRT の既定値である P4 を見て、根拠を読む前にクローズしてしまいます。必ず最初に記載してください。
• エンドツーエンドの証明なしで報告する — 悪用を実証していない観察結果は「理論上のもの」とみなされ、OOS としてクローズされます。攻撃経路全体をトリアージ担当者に説明できる場合にのみ報告してください。
• プリミティブを先に報告せずに連鎖させる — 連鎖の利用側が、まだ存在しないプリミティブの UUID を参照してしまいます。まずプリミティブを報告し、次に利用側を報告してから、UUID を後から埋めてください。
• 連鎖に関する報告を1件にまとめる — Bugcrowd の「修正1件につき報奨金1件」のルールでは、個別に修正できる箇所はそれぞれ別の報告にする必要があります。まとめずに、相互参照してください。
• OOS リスクのある発見を、明確な P3 より先に報告する — まず、適用範囲内であることが明確な確かな発見によって信頼を築いてください。OOS リスクのある報告は、確立した実績を踏まえて読まれることで有利になります。
• すべての発見を一度にまとめて送信する — 5分間にすべてを報告すると、手間をかけていないスパムのように見えます。少なくとも短い間隔を空けて送信してください。
• 連鎖の各要素を P1 と過大に主張する — 各プリミティブが単独で P1 になるわけではありません。各プリミティブ単体には適切な深刻度を主張し、深刻度の引き上げは連鎖の利用側に適用してください。
• Bugcrowdninja のエイリアスを忘れる — エイリアスを使わずにテストすると、トラフィックが詐欺の可能性ありとしてフラグ付けされます。Bugcrowd が管理するプログラムでは、必ず @bugcrowdninja.com のメールアドレスを使用してください。
• PoC の後にアカウントの状態を復元しない — パスワードやメールアドレスの変更など、状態を変更する PoC の後にアカウントを壊れた状態のままにすると、信頼を損ないます。すぐに復元し、その内容を記録してください。
• VRT の深刻度は固定だと思い込む — VRT の既定値はスキーマのバージョンやプログラムごとの設定によって変わります。記憶に頼らず、現在のフォームで実際に自動提案される内容を必ず確認してください。

---

9. 他のスキルとの併用

この質問／タスクの場合	このスキルを使用
「この発見を報告すべきですか？」	triage-validation（7つの質問によるゲート）
「Bugcrowd の報告本文のテンプレートはどれですか？」	report-writing
「どの VRT を選べばよいですか？」	このスキル（bugcrowd-reporting）§1
「深刻度の引き上げをどのように主張すればよいですか？」	このスキル §2-3
「OOS の異議にどう反論すればよいですか？」	このスキル §4
「スクリーンショット内の Cookie／PII をどうマスキングすればよいですか？」	evidence-hygiene
「この悪用手順のペイロードはどこにありますか？」	security-arsenal
「このアセットの種類に対する偵察プローブはどこにありますか？」	offensive-osint

---

検証

このセルフテストを実行して、報告の準備ができていることを確認してください。

1. VRT 検索テスト — Bugcrowd の VRT インターフェースを操作できることを確認します。

   • Bugcrowd の提出ドラフトを開く
   • VRT のドロップダウンで「IDOR」、「XSS」、「Broken Access Control」を検索する
   • 各検索語に対して少なくとも1件の一致が表示されることを確認する

2. 深刻度の引き上げ要求テンプレートのテスト — テンプレートが正しく表示されることを確認します。

   grep -q "Severity request — please review carefully" SKILL.md && echo "PASS: template present" || echo "FAIL"
   grep -q "The closest VRT category" SKILL.md && echo "PASS: justification structure present" || echo "FAIL"
   

3. OOS 反論テンプレートの有無 — 5つの反論テンプレートがすべて存在することを確認します。

   for clause in "Rate limiting on non-authentication" "Debug information disclosure" "User enumeration with low-risk" "Theoretical issues" "end-to-end proof"; do
     grep -q "$clause" SKILL.md && echo "  OK: $clause" || echo "  MISSING: $clause"
   done
   

4. 相互参照 UUID の形式 — 連鎖リンクの UUID パターンが文書化されていることを確認します。

   grep -q "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX" SKILL.md && echo "PASS: UUID format documented" || echo "FAIL"
   

5. Bugcrowdninja エイリアスの認識 — エイリアスの使用方法が文書化されていることを確認します。

   grep -q "bugcrowdninja.com" SKILL.md && echo "PASS: alias documented" || echo "FAIL"
   

5つのテストすべてで、このスキルの重要なテンプレートが揃っていることを確認できます。

---

使用上の注意

このスキルは小規模で、用途を絞っています。report-writing の内容（プラットフォームごとのテンプレート、CVSS スコアリング、評価引き下げへの対処、提出前の 60 秒チェックリスト）を重複して掲載していません。Bugcrowd のレポートを提出する際は、両方のスキルを読み込んでください。両スキルの役割分担は明確で、内容を自然に組み合わせられます。report-writing は本文のテンプレートを提供し、bugcrowd-reporting はその上にプログラム固有の戦術を重ねます。

---

関連スキルと連携

• report-writing — bugcrowd-reporting と常に併せて読み込んでください。ワークフローの基本要素：report-writing が本文の骨組みを提供し、このスキルがその骨組みに VRT の選定、深刻度を求める段落、OOS 条項への反論を重ねます。
• triage-validation — Bugcrowd に提出する調査結果がトリアージを通過するかを判断する際に使用します。ワークフローの基本要素：最初に 7Q ゲートを実施し、検証済みの調査結果のみが VRT の対応付けのためにこのスキルに進みます。
• evidence-hygiene — Bugcrowd の提出物にスクリーンショット／HAR を添付する際に使用します。ワークフローの基本要素：Bugcrowd の非公開添付システムでは証拠のマスキングが必要です。添付をクリックする前に、すべての証拠を evidence-hygiene に通してください。
• security-arsenal — PoC の手順でペイロードをそのまま引用する必要がある際に使用します。ワークフローの基本要素：このスキルのレポート本文にある「再現手順」セクションでは、正確なペイロードを security-arsenal から取得するため、トリアージ担当者は貼り付けて実行できます。
• bb-methodology — エンゲージメントの形式がバグバウンティ（レッドチームではない）であることを確認する際に使用します。ワークフローの基本要素：bb-methodology の PART 0 で「バグバウンティか」を確認します。該当し、かつ対象が Bugcrowd の場合、このスキルがレポート作成の補助として適用されます。