report-generate

ペネトレーションテスト報告書の作成方法

報告書はペネトレーションテストの最終成果物です。どれほど優れた攻撃を行っても、報告書が適切に作成されておらず、顧客に内容が伝わらなければ、実施した意味がありません。

データの収集

まず、既存のデータをすべて収集します。

• get_store_stats — 全体の統計
• evidence_list（種類で絞り込み）— 資産一覧
• list_vulns — 脆弱性一覧
• evidence_list + evidence_read（認証情報の種類で絞り込み）— 認証情報（マスキングして報告書に掲載）

報告書の構成テンプレート

1. エグゼクティブサマリー（1 ページ、経営層向け）

専門用語を使わずに概要を説明します。

• 評価範囲と期間
• 一言での結論：全体的なセキュリティ状況（例：「重大な脆弱性が 3 件見つかり、攻撃者がリモートからサーバーを完全に制御できる」）
• 主要な数値：資産数、脆弱性数（深刻度別）
• 最も緊急性の高い対応項目

2. 評価範囲と手法

• 対象一覧（ドメイン／IP／アプリケーション）
• テストの種類（ブラックボックス／グレーボックス／ホワイトボックス）
• 使用した方法論とツール
• 制約事項（期間、対象範囲からの除外）

3. 発見事項の概要

脆弱性の統計グラフ：

严重: ■■ 2
高危: ■■■ 3
中危: ■■■■■ 5
低危: ■■■ 3
信息: ■■■■■■ 6

4. 脆弱性の詳細（中核部分）

各脆弱性を、次の構成で記述します。

[重大] SQL インジェクション — ユーザー検索機能

• 場所：https://target.com/search?q=
• 説明：検索パラメーターがフィルタリングされずに SQL クエリへ直接連結されているため、攻撃者はデータベースの内容を読み取り／変更／削除できます。
• 影響：すべてのユーザーデータ（パスワードハッシュを含む）を取得でき、サーバー上のファイルを読み取れます。
• 再現手順：
  1. https://target.com/search?q=' OR 1=1-- にアクセスします。
  2. ページにすべてのレコードが返されます（通常は一致する項目のみが返されるべきです）。
  3. UNION SELECT を使用すると、users テーブルのデータを抽出できます。
• 修正案：パラメーター化クエリ（プリペアドステートメント）を使用し、SQL 文字列の連結を禁止します。

5. リスク評価基準

CVSS 3.1 または簡易版を使用します。

レベル	CVSS	典型的な例
重大	9.0-10.0	RCE、シェルを取得できる SQL インジェクション、認証の完全な回避
高	7.0-8.9	機密データの漏えい、権限昇格、任意ファイルの読み取り
中	4.0-6.9	格納型 XSS、CSRF、情報漏えい
低	0.1-3.9	反射型 XSS、ディレクトリ一覧、バージョン情報の漏えい
情報	0	セキュリティ設定に関する推奨事項、ベストプラクティスからの逸脱

6. 修正案の優先順位

修正の緊急度が高い順に並べます。

1. 直ちに修正：重大および高の脆弱性
2. 計画的に修正：中の脆弱性（次のリリース）
3. 適宜改善：低および情報レベル

7. 付録

• ツール一覧とバージョン
• 詳細なテストのタイムライン
• 元のスキャンデータ（任意）

執筆の原則

• 再現可能：技術者が再現手順を読んで自分で検証できるようにします。小規模な PoC は再現手順に記載し、長い PoC は付録に掲載して本文から参照します。
• 理解しやすい：経営層がエグゼクティブサマリーを読んでリスクを理解できるようにします。脆弱性の影響は技術用語だけでなく、業務への影響として記述します。
• 実行可能：修正案はコード／設定レベルで具体的に記述します。
• 誇張しない：リスクを客観的に記述し、重要に見せるためにレベルを引き上げないようにします。
• 納品可能：最終成果物には PDF を優先します。編集可能な Word／Markdown／LaTeX のみを納品物にしないでください。
• 主観的で感情的な表現を避け、専門的な姿勢を保ちます。

納品品質のチェック

機密情報のマスキング

• パスワード、Token、身分証明書、個人写真、顧客データは、元に戻せない方法で覆い隠します。半透明のぼかしだけを使わないでください。
• スクリーンショットを文書に挿入する前に、画像ファイル上でマスキングを完了します。Word 内の図形による覆い隠しに頼らないでください。元の画像が文書パッケージ内に残っている可能性があります。
• 認証情報は、特定に必要な先頭と末尾のみを残します。例：AKIA...ABCD

スクリーンショットの基準

• 脆弱性を証明できる最小限の範囲だけをスクリーンショットに残し、コマンド、URL、ステータスコード、重要なレスポンスを読み取れるようにします。
• 暗色で透明なターミナルは避けます。報告書は印刷または圧縮されることが多く、コントラストの低いスクリーンショットは判別しにくくなります。
• 画像ごとにタイトルまたは説明を付け、重要な証拠を強調します。
• コマンドラインのスクリーンショットには実際のコマンドを含めます。出力だけのスクリーンショットでは再現が困難です。

文書の整理

• リストは重複を削除して並べ替えます（深刻度、ドメイン、IP、ポート、またはタイムライン順）。
• 「複数」「いくつか」などの曖昧な数量を避け、数値化できる場合は具体的な数量を記載します。
• 顧客の機密データを管理されていないオンライン LLM に送信しないでください。執筆支援が必要な場合は、ローカルモデルを優先するか、事前にマスキングします。
• 納品前に、スペル、リンク、画像の鮮明さ、目次、ヘッダーとフッター、添付ファイルに不備がないか確認します。