脆弱性診断の報告書サンプルの見方｜発注前に確認する項目

脆弱性診断の報告書サンプルを受け取ると、見た目の整い方やページ数で比較したくなることがあります。しかし、発注前に確認したいのは、どの対象を確認したか、事実と影響をどう分けるか、優先度と修正確認をどう記録するかです。

結論から言うと、報告書サンプルは見栄えではなく、対象・事実・優先度・修正確認が読み取れるかで確認します。実際の未公表情報や詳細な弱点の開示を求めず、公開可能な範囲で構成と記載粒度を比べます。

発注前に、各社へ同じ質問を出し、対象記載、報告形式、修正案の記載、再確認の記録、共有・保管の条件を比較表にまとめます。サンプルを読む担当と、発注後に結果を受け取る担当も決めておきましょう。

本記事で分かること

• 報告書サンプルで確認する四つの記載
• 各社にそろえて質問する項目
• 機微情報を扱わない比較方法
• 報告後の修正・再確認へのつなげ方

結論：報告書は四つの記載で確認する（早見表）

報告書サンプルは、対象、事実、優先度、修正確認が読み取れるかで確認します。サンプルの形式が違っても、同じ比較表の欄へ写し、発注時の対象表と照合できるかを見ます。

サンプルで確認できる項目

機微情報を求めず、構成と記載粒度を確認します。公開可能なサンプルで、対象の示し方、影響と優先度の整理、修正後の確認の記録を比較します。

対象と確認時点

サンプルでは、対象にした資産、画面、機能、認証後の範囲、対象外をどのように記載しているかを確認します。対象が分かれば、発注時の対象表と報告書を照合し、今回確認していない範囲を関係者で共有できます。対象名だけでなく、確認した時点や環境の記載も見ます。

対象の書き方を確認する際は、実際の顧客名や未公表の構成を求めません。公開可能な例で、対象・対象外・確認時点を分けて記載する構成があるかを確認します。セキュリティ診断の発注ガイドを参照し、自社の対象表に必要な欄をそろえます。

影響と優先度

影響と優先度では、確認した事実と、対応の順番を考えるための整理が分けて書かれているかを見ます。技術的な説明だけでなく、どの対象、利用者、業務機能に関係するかを確認できる構成かを質問します。優先順位の最終判断を誰が行うかも発注条件に記載します。

サンプルで具体的な未公表情報を確認する必要はありません。見出し、対象の記載、判断のための欄、対応状況の整理など、公開可能な構成で比較できます。依頼先ごとの表現が違う場合も、比較表では対象・事実・優先度の同じ欄へ写します。

修正の確認方法

修正の確認方法では、修正した対象、確認する版、再確認の結果をどのように記録するかを確認します。報告を受けることと、修正後の確認が完了することを同じ扱いにせず、対象・担当・結果の受け方を分けます。発注前に再確認の条件を確認します。

脆弱性診断の費用構造を参照し、対象、成果物、再確認の条件を比較表にそろえます。サンプルに再確認の記載がある場合は、どの対象と条件で記録されるかを質問します。自社の修正担当と報告書を受け取る担当も対応付けます。

比較時に質問する項目

同じ質問を各社へ出し、回答条件をそろえます。報告書の形式、修正案の記載、再確認の記録を別の質問にし、回答を比較表へ残します。

報告書の形式

報告書の形式では、対象、対象外、確認時点、共有先が分かるかを質問します。文書の見た目だけでなく、発注時の対象表のどの行と照合できるかを確認します。対象の認識に差が出た場合に、どの窓口へ質問するかも整理します。

依頼先ごとに形式が違う場合でも、比較表には対象・事実・優先度・修正確認の同じ欄を作ります。回答を受けたら、自社が必要とする報告の受け手と共有方法に対応付けます。形式を一律にすることより、必要な項目を確認できることが重要です。

修正案の記載

修正案に関する記載では、対象となる機能・連携・設定を、自社の修正担当が確認できる形で整理できるかを質問します。具体的な未公表情報をサンプルとして求めず、対象と修正確認の関係をどのように記録するかを確認します。対応の判断は自社の変更管理に沿って行います。

修正担当が複数いる場合は、報告書の情報をどのように共有するかを決めます。対象表のどの行に関係するか、誰が完了を確認するか、再確認が必要かを対応表に残します。報告書の記載と自社の作業依頼を同じものとして扱わず、役割を分けます。

再確認の記録

再確認の記録では、どの対象、どの版、どの条件で確認したか、結果を誰が受け取るかを確認します。修正後に対象が変わった場合は、当初の対象表との差分を残します。再確認する範囲と、再確認しない範囲を区別して記録します。

手動診断とツール診断の違いを参照し、確認方法の名称ではなく、再確認で何を確認するかを仕様として整理します。報告書サンプルで記録の構成を確認し、自社の対象・修正・再確認の条件に対応付けます。

機微情報を扱うときの注意

実データや未公表の弱点を要求せず、公開可能な範囲で確認します。サンプルの共有範囲、保管場所、閲覧者、返却の条件を発注前に整理し、必要な担当者だけが扱う体制にします。

匿名化の扱い

サンプルを確認する際は、公開可能な範囲に整理された例で構成と記載粒度を見ます。実在の顧客名、実データ、未公表の弱点、再現に関する詳細を求めません。どの情報が共有可能かは、依頼先と自社の取扱い条件に沿って確認します。

匿名化された例でも、対象、確認時点、事実、優先度、修正確認の構成を比較できます。サンプルの内容を自社の対象にそのまま当てはめず、必要な記載をRFPや報告条件へ反映します。共有前に、誰が確認するかを決めます。

共有範囲

共有範囲は、報告書サンプルを読む必要がある担当者に限定します。発注、開発、運用、契約の担当が関わる場合も、誰がどの目的で確認するかを整理します。共有する情報と、共有しない情報を分け、転送や保管の方法を確認します。

共有後に質問が出た場合は、窓口を通じて対象と目的に結び付けて確認します。サンプルを広く配布することを前提にせず、必要な情報を必要な担当者へ渡す体制にします。共有範囲に変更があった場合は、記録を更新します。

保管と返却

保管と返却では、サンプルをどこに保管し、誰が閲覧し、確認後にどう扱うかを整理します。自社の情報管理のルールと契約上の条件を確認し、保管する担当と連絡窓口を決めます。保管場所を決めることと、共有範囲を決めることを別に扱います。

確認が終わった後は、保管・返却の条件に沿って扱い、対応した担当を記録します。サンプルを発注後の報告書と同じ方法で扱うかは、対象情報と共有条件を踏まえて判断します。必要な担当だけが経緯を確認できるようにします。

まとめ

脆弱性診断の報告書サンプルは、対象、事実、優先度、修正確認が読み取れるかを同じ比較表で確認します。機微情報を求めず、公開可能な構成と記載粒度、共有・保管の条件を整理し、発注後の修正・再確認へつなげましょう。

報告書の確認は、セキュリティ診断の発注ガイドと、進め方の記事一覧から確認できます。