コース目次 / 第4章
報告書を書く — 実務レベルのフルテンプレ
sec-disclosureの1件用テンプレを、複数の発見をまとめる正式な診断報告書に発展させます。要旨・スコープ再掲・手法・発見一覧・発見ごとの詳細・総評という構成を、実際に手元で書きます。
sec-disclosure で、1件の脆弱性の報告テンプレを書きました。実務の診断報告書は、それを複数件まとめ、全体像を添えたものです。この章で、フルの構成を組み立てます。
報告書全体の構成
1. 表紙・概要情報 — 対象・実施期間・実施者。
2. エグゼクティブサマリー(要旨) — 経営層や非技術者向けに、全体の結論を数行で。「重大な問題が◯件、うち急ぎ対応が必要なものが◯件」。
3. スコープの再掲 — 第1章で確定した対象・期間・手法を、報告書にも明記する(あとから「これは対象外では」という揉め事を防ぐ)。
4. 手法(methodology) — どう診断したか(手動中心か、ツールを併用したか)の概要。
5. 発見の一覧(サマリーテーブル) — 全発見を、重大度とタイトルだけで一覧表にする。
6. 発見ごとの詳細 — sec-disclosure で書いた型を、1件ずつ。
7. 総評 — 全体を通して見えた傾向(例:「認可チェックの実装が場当たり的」)。個別の穴ではなく、根っこの傾向を指摘する。
なぜ「要旨」と「詳細」を分けるのか
報告書を読む人は、一様ではありません。経営層は「予算をどれだけ緊急に割くべきか」を数行で知りたい。開発者は「どこを・どう直せばいいか」を手順まで正確に知りたい。
1つの文書で、両方に応えます。要旨は平易な言葉で結論だけ、詳細は技術的に正確に。冒頭の要旨だけ読んでも意思決定ができ、必要な人は詳細まで降りていける——この階層構造が、実務の報告書の型です。
発見一覧(サマリーテーブル)の例
■ 発見の一覧
| No | タイトル | 重大度 |
|----|----------------------------------|--------|
| 1 | メモ詳細表示における認可不備(IDOR) | 高 |
| 2 | 検索機能における反射型XSS | 高 |
| 3 | ログイン後リダイレクトの未検証 | 中 |
| 4 | セキュリティヘッダーの一部欠落 | 低 |一覧を見ただけで、依頼主は「何から手をつけるべきか」を掴めます。
発見ごとの詳細 — sec-disclosureの型を、思い出す
各発見は、sec-disclosure で書いたこの型をそのまま使います。
■ No.1 メモ詳細表示における認可不備(IDOR)
重大度: 高(可能性: 高 / 影響: 高)
対象: GET /notes/:id
概要: ログイン中の利用者が、URLのIDを変更するだけで、他利用者の
非公開メモを閲覧できる。
再現手順:
1. http://127.0.0.1:3000/login?as=u1 でログイン
2. http://127.0.0.1:3000/notes/3 を直接開く
→ 期待: 403。実際: 200 で他利用者(u2)のメモが表示される
影響: 全利用者の非公開メモが、ID を連番で試すだけで漏洩しうる。
修正の提案: メモを返す前に、所有者と現在の利用者が一致するかを
サーバ側で確認し、不一致なら403を返す。
切り分け: 本発見の確認に必要な最小限のみ実施。データの保存・
外部への持ち出しは行っていない。重大度は前章で決めた基準を、切り分けは sec-disclosure で学んだ節度を、それぞれ明記します。読み手にとっては、この1件の型さえ守られていれば、報告書のどの発見も同じ形で読める——形式の統一が、読みやすさを作ります。
演習 — 1本、書いてみる
これまでのコースで見つけた穴から、2〜3件を選び、上の構成で報告書を組み立ててみてください。
すべて手元で完結する演習です。実在の窓口には送信しません。要旨・発見一覧・発見ごとの詳細の3つがそろえば、十分に実務の骨格を持った報告書です。総評(全体の傾向)まで書ければ、なお実務に近づきます。
持ち帰る一言
要旨で結論を、詳細で手順を。 経営層と開発者、両方に届く階層構造を作り、発見一覧で優先度を一目にし、各発見は sec-disclosure の型で統一する。これが、対価に見合う報告書の骨格です。次はまとめて、提出後の振る舞いまで見届けます。
こうなっていればOK
卒業まであと1章です。
この章はまだ完了していません。
保存できませんでした(プライベートブラウズ中かもしれません)。この端末に進捗は残りませんが、先へは進めます。