bug-bounty-report-writing について
バグバウンティの調査結果を、根拠に基づく報告書にまとめるためのスキルです。構成、影響の説明、証拠内の個人情報保護、提出後の対応を扱います。
主な機能
- 01脆弱性報告書の構成
- 02再現可能な手順の作成
- 03証拠に基づく影響の説明
- 04証拠内の個人情報保護
- 05提出後の審査対応
活用シーン
- 01脆弱性報告の準備
- 02再現手順の記録
- 03影響と深刻度の評価
- 04トリアージ担当者への回答
インストール
コマンドをコピーしてターミナルで実行します。
$
npx skills add https:/インストール後、Claude Code で/bug-bounty-report-writingを入力して読み込まれたか確認します。
詳細
バグバウンティレポートの作成
発見事項を、トリアージ担当者が迅速に受け入れ、公正に評価できるレポートにまとめます。
レポートの構成
- タイトル — 脆弱性の種類＋影響を受ける資産。
Stored XSS in ticket comment field on support.example.com - 重大度と CVSS — 推奨する評価とベクター文字列
- 概要 — 2～3 文で、何が、どこで起きるか、影響を説明します
- 再現手順 — 番号付きで、コピーして実行でき、前提条件のない手順
- 影響 — 攻撃者が得るものを具体的に説明します
- 裏付け資料 — HTTP リクエスト／レスポンス、機密データをマスキングしたスクリーンショット
- 修正方法 — 具体的な修正案
ルール
- 1 件のレポートにつき脆弱性は 1 つです。各ステップが単独では意味をなさない場合に限り、攻撃チェーンを 1 件のレポートにまとめます。
- 影響は推測ではなく、実証するか、論理的に厳密な説明を示す必要があります。攻撃経路を示さずに「RCE につながる可能性がある」と述べても、評価は下がります。
- 証拠に含まれる個人データはマスキングしてください。ユーザーの PII はぼかし、アクセスした他のユーザーのデータは決して含めないでください。アクセスしたことを報告し、データを削除してください。
- 貼り付けたログの書式が Markdown を壊さないようにしてください。コードフェンスを使用してください。
- その資産を初めて見るトリアージ担当者を想定して書いてください。
評価が下がるよくある原因
- 自己 XSS や、被害者がソフトウェアをインストールする必要がある XSS を高い重大度として報告する
- 実証された悪用がないのに、
Content-Security-Policyの欠如や詳細すぎるヘッダーを指摘する - 異なる 2 つのアカウントへの影響を示さず、理論上の IDOR を報告する
- 手動で検証せず、自動スキャナーの出力を貼り付ける
提出後
- プログラムの SLA に従い、トリアージ担当者からの質問に回答してください
- 実質的な新情報が得られた場合に限り、再レビューを依頼してください
- プログラムの開示ポリシーで許可されるまで、一般公開しないでください
コメント
Markdown 対応