脆弱性診断の報告書には何が書かれるか。構成サンプルと深刻度（CVSS）の読み方、経営層と技術者で見る場所の違い

脆弱性診断を発注すると、最後に「報告書」が届きます。数十ページにわたって脆弱性の一覧とスコアが並び、どこから読めばよいのか分からない、という声をよく聞きます。報告書を受け取って終わりにしてしまうと、診断に払った費用は「点検した記録」にしかなりません。

本記事では、脆弱性診断の報告書に何が、どの順番で書かれるのかを構成サンプルで示し、深刻度の指標であるCVSSの読み方と、経営層と技術者がそれぞれどこを読めばよいかを整理します。これから診断を発注する方は、見積もりの段階で「報告書にこれが入っているか」を確認するチェックリストとしても使えます。診断の種類そのものは『脆弱性診断とは』で解説しています。

この記事の要点

脆弱性診断の報告書は、おおむね「表紙・診断概要・総合評価（経営層向けサマリー）・検出結果一覧・個別の脆弱性の詳細・付録」の6部で構成されます

経営層は総合評価と検出結果一覧の2つだけ読めば判断できるように作るのが基本です。技術者は個別の脆弱性の詳細（再現手順・影響・対策）を使って修正します

深刻度の多くはCVSSで示されます。CVSSのスコア（0.0〜10.0）は「緊急・重要・警告・注意」などの段階に読み替えられますが、FIRSTの仕様書は、基本値に加えて自社の環境に合わせた評価を行うよう求めています

スコアだけで順番を決めず、「インターネットから届くか」「実際に悪用されているか」「漏れたら困る情報があるか」で優先順位を付け直すのが実務です

報告書で必ず確認したいのは、診断の範囲・日時・方法です。診断していない場所は「問題なし」ではなく「未確認」です

報告書の全体構成（サンプル）

まず全体像です。診断会社によって章の名前や順番は違いますが、中身はおおむね次の6部に収まります。

部	主な内容	主な読み手
① 表紙・管理情報	報告書名、診断対象のシステム名、発行日、版数、取り扱い区分（社外秘など）	全員
② 診断概要	診断の目的、対象（URL・IPアドレス・ホスト名）、診断期間、診断方法（ツール・手動）、診断の基準、対象外とした範囲、前提条件	担当者・監査対応
③ 総合評価（エグゼクティブサマリー）	全体の評価、深刻度別の件数、特に急ぐべき項目、推奨する対応方針と期限	経営層・責任者
④ 検出結果一覧	検出した脆弱性の一覧表（番号・名称・対象・深刻度・対応の優先度）	責任者・技術者
⑤ 個別の脆弱性の詳細	1件ごとの説明、該当箇所、再現手順または根拠、想定される影響、対策方法、参考情報	技術者・開発会社
⑥ 付録	診断項目の一覧、使用したツールとバージョン、診断時の通信ログの抜粋、用語集	技術者・監査対応

報告書の厚さの大半は⑤と⑥です。逆に言えば、判断に必要な情報は③と④に集約されているので、経営層が全ページを読む必要はありません。

① 表紙・管理情報

地味ですが、後で効いてくるのがここです。報告書は取引先への説明や監査の証跡として社外に出ることがあり、その際に「いつ時点の、どのシステムの、何版の報告書か」が曖昧だと説明に困ります。修正後に再診断した場合は、版数を上げて初回と区別します。

報告書には脆弱性の所在と再現方法が書かれているので、それ自体が攻撃者にとって価値のある情報です。取り扱い区分を明記し、社外に出すときは総合評価だけを抜き出すか、後述の診断実施証明書を使うのが安全です。

② 診断概要

報告書の中で、いちばん見落とされ、いちばん重要な章です。次の項目がそろっているかを確認してください。

項目	書かれているべき内容	抜けていると困ること
対象	URL、IPアドレス、ホスト名、画面・機能の範囲	診断していない場所まで「問題なし」と誤解される
期間	診断を行った日時（開始・終了）	その後に追加・変更した部分が診断済みかどうか分からない
方法	ツール診断か手動診断か、使ったツール、ログインの有無	結果の確からしさ（見逃しの可能性）を判断できない
基準	何を基準に診断項目を選んだか、深刻度の付け方	他社の報告書や前回の結果と比べられない
対象外	診断しなかった範囲とその理由	「全体を診断した」と誤って説明してしまう
前提条件	本番か検証環境か、WAFなどの防御を外したか	本番環境と結果が違う理由が分からない

たとえば、ログインせずに外側だけを診断した場合、ログイン後の画面にある脆弱性は見つかりません。その場合、報告書には「ログイン後の機能は対象外」と書かれているはずで、この一文を読み飛ばして「診断済み」と社内報告すると、後で説明がつかなくなります。**診断していない場所は「問題なし」ではなく「未確認」**です。

③ 総合評価（エグゼクティブサマリー）

経営層・責任者が読むページです。1〜2ページに、次の内容がまとまっているのが望ましい形です。

全体の評価（例：「重大な問題が1件あり、早急な対応が必要」「重大な問題は検出されなかった」）
深刻度別の件数（緊急◯件・重要◯件・警告◯件・注意◯件）
特に急ぐべき項目と、その理由を技術用語を使わずに説明したもの（例：「会員の個人情報が外部から読み取れる可能性がある」）
推奨する対応の順番と期限の目安
再診断の要否

経済産業省とIPAの「サイバーセキュリティ経営ガイドライン Ver 3.0」は、経営者がセキュリティリスクを認識し、対応方針や予算・人材の確保を担当幹部に指示することを求めています。総合評価は、経営者がその判断を下すための材料です。**「何件あったか」より「何が起きうるか」と「いつまでに何をするか」**が書かれているかを見てください。

④ 検出結果一覧

1行1件の一覧表です。サンプルを示します（内容は説明のための例です）。

No.	脆弱性の名称	対象	深刻度	優先度	対応の目安
1	古いバージョンのWebサーバーソフトウェアの使用（既知の脆弱性あり）	www.example.co.jp	重要	高	1週間以内
2	管理画面がインターネットから誰でもアクセスできる	admin.example.co.jp	警告	高	1週間以内
3	検索画面のクロスサイト・スクリプティング	www.example.co.jp/search	警告	中	1か月以内
4	Cookieにセキュリティ属性が付いていない	www.example.co.jp	注意	低	次回改修時
5	エラーメッセージにソフトウェアのバージョンが表示される	api.example.co.jp	注意	低	次回改修時

ここで注目してほしいのは、「深刻度」と「優先度」が別の列になっている点です。No.2は深刻度こそ「警告」ですが、管理画面が誰でも触れる状態は侵入の入口になりやすいため、優先度は「高」にしています。この2つを分けて書いている報告書は、診断した人が自社の状況まで踏み込んで判断していると言えます。

⑤ 個別の脆弱性の詳細

技術者や開発会社が修正に使う部分です。1件ごとに、次の項目が書かれます。

項目	内容
概要	どのような脆弱性か
該当箇所	URL、パラメータ、ホスト、ポートなど
根拠・再現手順	診断時に送ったリクエストと応答、検出したバージョン情報など
想定される影響	悪用されると何が起きるか（情報の読み取り、改ざん、なりすましなど）
深刻度	CVSSのスコアとベクトル（評価の内訳）、または独自基準の段階
対策	根本的な対策と、すぐにできる暫定対策
参考情報	CVE番号、JVN・ベンダーの公表情報、IPAの解説資料など

「対策」の欄が「適切に対策してください」の一行で終わっている報告書は、修正の段階で手が止まります。根本対策（例：ソフトウェアの更新）と暫定対策（例：管理画面に接続元のIP制限をかける）の両方が書かれているか、修正後の確認方法が示されているかを見てください。

⑥ 付録

診断項目の一覧（何を確認したか）、使用したツールとバージョン、通信ログの抜粋などです。普段は読みませんが、監査や取引先から「どのような診断をしたのか」と聞かれたときの根拠になります。次回の診断で同じ条件を再現するためにも保管しておきます。

深刻度（CVSS）の読み方

CVSSとは

CVSS（Common Vulnerability Scoring System、共通脆弱性評価システム）は、FIRST（Forum of Incident Response and Security Teams）が仕様を公開している、脆弱性の深刻度を0.0〜10.0の数値で表す共通の物差しです。現在は2023年11月に公開されたv4.0が最新版で、実務ではv3.1と併用されています。報告書にどちらの版で評価したかが書かれているかも確認してください。版が違うと、同じ脆弱性でもスコアが変わることがあります。

スコアと段階の対応

FIRSTの仕様書は、スコアを次の5段階に読み替える目安を示しています。IPAは日本語で「緊急・重要・警告・注意」と呼んでいます。

スコア	FIRSTの段階	IPAの日本語表記	報告書でよくある表記
9.0〜10.0	Critical	緊急	緊急／Critical
7.0〜8.9	High	重要	高／High
4.0〜6.9	Medium	警告	中／Medium
0.1〜3.9	Low	注意	低／Low
0.0	None	なし	情報

報告書によっては、CVSSではなく診断会社独自の「高・中・低」で付けていることもあります。その場合は、どういう基準で段階を決めたかが②の診断概要に書かれているかを確認してください。

スコアは「その脆弱性の重さ」で、「自社にとっての危険度」ではない

CVSSのスコアには、評価の観点ごとに種類があります。

評価の観点	v3.1での名前	v4.0での名前	何を表すか	時間や環境で変わるか
脆弱性そのものの性質	基本評価基準（Base）	Base	攻撃の難しさと、成功したときの影響	変わらない
いまの状況	現状評価基準（Temporal）	Threat	攻撃コードが出回っているか、対策が出ているか	時間とともに変わる
利用者の環境	環境評価基準（Environmental）	Environmental	自社のシステムでの重要度、すでにある防御	組織ごとに変わる

公開情報や診断ツールが付けるスコアの多くは、このうちの基本評価基準だけで計算されています。FIRSTのv3.1の仕様書は、利用者は基本値に加えて、自分たちの利用状況に応じた現状値と環境値で補うべきだとしています。v4.0では、どの観点まで評価したかが分かるよう「CVSS-B（基本のみ）」「CVSS-BTE（基本・脅威・環境）」といった表記を使うことになりました。

つまり、報告書に「CVSS 7.5」とあっても、それが一般論としての重さなのか、自社の環境を踏まえた重さなのかで意味が変わります。インターネットから届かない社内サーバーの「7.5」と、誰でもアクセスできる公開サーバーの「7.5」は、同じ順番で直すべきものではありません。

優先順位はスコア以外の情報で付け直す

実務では、CVSSのスコアに次の3つの観点を足して優先順位を決めます。

観点	確認すること	参考になる情報
届くか	インターネットから直接アクセスできるか、ログインが必要か	診断概要の対象とネットワーク構成
悪用されているか	実際の攻撃で使われているか、攻撃コードが公開されているか	米CISAの「KEVカタログ」（悪用が確認された脆弱性の一覧）、FIRSTの「EPSS」（今後30日以内に悪用される確率の推定）
失うものがあるか	個人情報、決済情報、取引先の情報、業務停止の影響	自社の情報資産の棚卸し

米CISAはKEVカタログを「実際に悪用された脆弱性の信頼できる情報源」と位置づけ、組織が脆弱性管理の優先順位付けに使うよう勧めています。報告書の優先度の欄が、こうした情報まで踏まえて付けられているかを見ると、診断の質が分かります。

経営層と技術者で、読む場所はこう違う

	経営層・責任者	技術者・開発会社
読む章	③ 総合評価、④ 検出結果一覧	④ 検出結果一覧、⑤ 個別の詳細、⑥ 付録
知りたいこと	事業にどんな影響があるか、何をいつまでに決めるか	どこを、どう直し、どう確かめるか
判断すること	対応の予算と期限、サービスの一時停止の要否、取引先・顧客への説明の要否	修正方法、修正の順番、暫定対策の実施
報告書に求めること	専門用語を使わない説明、件数より影響の説明	再現できる根拠、具体的な対策、参考情報

経営層向けと技術者向けを別の冊子に分ける診断会社もあります。社内の稟議や取締役会への報告には経営層向けだけを使い、技術者向けは修正を担当する人と開発会社にだけ渡す、という使い分けができます。脆弱性の詳細が社内に広く出回らないので、情報管理の面でも有利です。

報告書を受け取ったら確認すること

範囲・日時・方法が、発注時に合意した内容と一致しているか
対象外とされた範囲に、本当は診断すべき場所が含まれていないか
深刻度がCVSSのどの版・どの観点で付けられているか、独自基準ならその定義があるか
「緊急」「重要」の項目について、影響の説明と対策が具体的に書かれているか
修正後に再診断（修正確認）を受けられるか、その費用は含まれているか
社外に出すための要約版や証明書を発行してもらえるか

6は、取引先からのセキュリティチェックシートや監査で「診断を受けているか」と聞かれたときに効いてきます。報告書をそのまま渡すと脆弱性の詳細まで外に出てしまうので、診断の事実と結果の概要だけを示す書類を用意してもらうのが安全です。詳しくは『脆弱性診断の実施証明書は何に使えるか』で解説しています。

まとめ

脆弱性診断の報告書は「表紙・診断概要・総合評価・検出結果一覧・個別の詳細・付録」の6部で構成されるのが一般的です
経営層は総合評価と検出結果一覧、技術者は個別の詳細を読みます。判断に必要な情報は総合評価に集約されているべきです
最も見落とされやすいのは診断概要です。診断していない場所は「未確認」であり、「問題なし」ではありません
CVSSのスコアは脆弱性そのものの重さで、自社にとっての危険度ではありません。届くか、悪用されているか、失うものがあるかで優先順位を付け直します
報告書を受け取ったら、範囲・方法の一致、対策の具体性、再診断の有無、社外向けの要約や証明書の有無を確認します

よくある質問

Q. 脆弱性診断の報告書は何ページくらいになりますか？

診断の対象と検出件数によって大きく変わります。総合評価は1〜2ページに収め、残りは個別の脆弱性の詳細と付録になるのが一般的です。ページ数より、診断の範囲・方法が明記されているか、対策が具体的に書かれているかを確認してください。

Q. CVSSのスコアが高い順に直せばよいですか？

それだけでは不十分です。報告書やツールが示すスコアの多くは脆弱性そのものの性質だけで計算した基本値で、FIRSTの仕様書も利用者の環境に応じた評価で補うよう求めています。インターネットから届くか、実際に悪用されているか、漏れたら困る情報があるかを加えて優先順位を決めます。

Q. CVSSの「緊急」「重要」「警告」「注意」はどう区切られていますか？

IPAの表記では、9.0〜10.0が緊急、7.0〜8.9が重要、4.0〜6.9が警告、0.1〜3.9が注意です。FIRSTの仕様書ではそれぞれCritical・High・Medium・Lowと呼ばれています。

Q. 報告書をそのまま取引先に提出してもよいですか？

おすすめしません。報告書には脆弱性の所在や再現方法が書かれており、外部に出ると攻撃の手がかりになります。取引先への説明には、総合評価だけを抜き出した要約版や、診断の事実と結果の概要を記載した診断実施証明書を使うのが安全です。

Q. 「検出なし」と書かれていれば安全と考えてよいですか？

診断した範囲・時点・方法で検出されなかった、という意味にとどまります。対象外の範囲や、診断後に追加・変更した部分、新たに公表された脆弱性は含まれません。定期的な再診断と、ソフトウェアの更新の運用を続けることが前提です。

この記事に関連するサービス

TodoONada株式会社では、AIを活用したサーバー脆弱性診断を行っています。ツールによる診断結果をAIで整理・優先度づけし、技術者が確認したうえで、経営層向けの総合評価と技術者向けの詳細を分けた報告書をお渡しします。

AIサーバー脆弱性診断（報告書・診断実施証明書つき） — 公開サーバー・Webアプリ・クラウド設定の診断。調査報告書、経営層向けレポート、取引先や監査に使える診断実施証明書を発行します。費用は対象と範囲に応じてお見積もりします

ご相談はお問い合わせからお気軽にどうぞ。「報告書は受け取ったが読み方が分からない」というご相談も歓迎です。