pentest-reporting について
pentest-reportingは、検証済みのセキュリティ上の発見を、経営層が優先順位を判断し、エンジニアが再現・修正できる報告書にまとめるスキルです。深刻度評価、修正計画、完了までの再テストを扱います。
主な機能
- 01経営層と技術者向けの報告構成
- 02再現手順と修正案を含む指摘テンプレート
- 03CVSSと業務状況に基づく深刻度評価
- 04完了までの再テスト追跡
活用シーン
- 01検証済みのペンテスト結果から報告書を作成
- 02エンジニアリングチームの修正優先度付け
- 03高深刻度の問題の再テスト結果を記録
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/pentest-reportingを入力して読み込まれたか確認します。
同梱ファイルreferences/cvss-and-template.md
詳細
ペンテストレポート（REPORT フェーズ — 作業を成果につなげる仕上げ）
概要
修正されない脆弱性は、セキュリティとは言えません。このフェーズでは、生の調査結果を、エンジニアが対応でき、リーダーが優先順位を付けられるレポートにまとめます。一貫した深刻度、明確な再現手順、正確な影響、具体的な修正策、そして追跡可能なクローズを実現します。
基本原則： 2 人の読者を同時に想定して書きます。リスクと優先順位を知る必要がある経営層と、正確な再現手順と修正方法を必要とするエンジニアです。
優れたレポートの構成
- エグゼクティブサマリー — 平易な言葉でリスク状況、上位 3～5 件のリスク、全体的な評価を記載します。専門用語は使いません。
- スコープと手法 — テスト対象、環境、実施日、対象外とした項目を記載します。
- 調査結果 — 各項目を 1 件ずつ記載します（テンプレートを参照）。深刻度順に並べます。
- 修正ロードマップ — 作業量の見積もりを含む、優先順位付きの修正リストです。
- 再テスト結果 — 修正後の各項目のステータス（Open / Fixed / Risk-accepted）です。
- 付録 — ツール、生の証拠、参考資料です。
脆弱性のテンプレート（すべての問題に使用）
Title: <Concise, e.g. "IDOR in /api/invoices exposes other users' billing">
Severity: Critical | High | Medium | Low | Info (CVSS x.x — vector)
Affected: <endpoint / file:line / component>
Summary: <1–2 sentences: what's wrong and why it matters>
Reproduction: <numbered, copy-pasteable steps / exact request>
Evidence: <response excerpt / screenshot, real data redacted>
Impact: <business consequence: data exposed, money, accounts, scope>
Remediation: <specific fix, link to security-hardening pattern>
Status: Open | Fixed (retested <date>) | Risk-accepted
深刻度と CVSS
優先順位を正当化できるよう、一貫性のあるスコアを付けます。CVSS v3.1 のメトリクス、基本スコアの早見表、レポートの完全なひな形については、references/cvss-and-template.md を参照してください。
| 深刻度 | CVSS の目安 | 意味 |
|---|---|---|
| Critical | 9.0–10.0 | ただちに修正 — 完全な侵害／大量のデータ／認証不要の RCE |
| High | 7.0–8.9 | 今サイクル中に修正 — ATO、機密データ、権限昇格 |
| Medium | 4.0–6.9 | 計画的に対応 — 条件が必要、または影響が限定的 |
| Low | 0.1–3.9 | バックログ — 軽微／多層防御 |
| Info | 0.0 | 情報 — ベストプラクティスに関する指摘で、直接的なリスクはありません |
ビジネス上の状況に応じて調整してください。決済経路における「Medium」は、あなたにとって「High」かもしれません。
執筆ルール
- 再現できなければ、起きていないのと同じです — 開発者がコピーして再実行できる手順を記載します。
- ビジネス上の影響を記載します — 「すべてのユーザーが全請求書を閲覧できる」と書き、「認可チェックがない」とは書きません。
- 1 件の調査結果につき修正は 1 つ — 正確な
security-hardeningのパターンを示します。 - 煽らず、無駄なく — 深刻度を正確に評価します。過大評価は信頼を損ない、過小評価は無視される原因になります。
- 証拠に含まれる実データはマスキングします。
再テストとクローズ
修正済みの各調査結果について、元の PoC を再実行し、合否と日付を記録して、ステータスを設定します。すべての High 以上がFixedになるか、責任者によって明示的にRisk-acceptedとされるまで、レポートは完成ではありません。
引き継ぎ
調査結果はすべての FIND／EXPLOIT スキルから集まり、修正は security-hardening が担当します。このスキルはそれらを整理し、クローズまで追跡します（修正済みとする前に、High 以上をそれぞれ再テストします）。
よくある間違い
- スキャナーの出力をそのまま「レポート」として提示する — まずトリアージ、重複排除、検証を行います。
- 勘で深刻度を決める — CVSS とビジネス上の状況を使い、優先順位に根拠を持たせます。
- 自分にしか分からない再現手順 — 初めて読む人にも分かるように書きます。
- 再テストをしない — エクスプロイトを再実行せずに「修正済み」と判断するのは、推測にすぎません。