脆弱性診断の報告書には「緊急」「重大」といったリスクレベルやCVSSスコアが並ぶ。しかし、その数字だけではどの問題をいつまでに誰が直すべきかは決まらない。診断結果を対策につなげるには、報告書の評価をどう読み解けばよいのか。
診断報告書が示すのは「検査時点」と「検査範囲」だけ
脆弱性診断とは、企業や組織のシステムに存在するセキュリティ上の問題点を、あらかじめ決めた範囲と手法で確認する検査だ。Webアプリケーション診断では、入力値の処理、認証、セッション管理、アクセス制御、重要情報の取り扱いなどを確認する。ネットワーク診断では、外部または内部から到達できるポートやサービス、OSやミドルウェアのバージョン、機器の設定、パッチの適用状況などが主な対象になる。
ここで押さえておきたいのは、診断結果が検査時点における状態の「スナップショット」であることだ。問題が検出されなかったとしても、その後の安全性や、あらゆる攻撃への耐性が保証されるわけではない。新たな脆弱性は継続して公表され、機能追加や設定変更によって、診断時には存在しなかった問題点が生じることもある。もう一つの制約が診断範囲だ。対象に含まれなかったURLやAPI、権限別アカウント、IPアドレス、ネットワーク区間は、診断結果の対象外となる。
独立行政法人情報処理推進機構（IPA）も、公開、運用後のWebサイトについて、サーバやネットワーク機器、Webアプリケーションを対象とする検査や監査を定期的に継続する重要性を示している。診断前に対象資産と変更箇所を把握し、何をどこまで確認したのかを記録することが、結果を読むための前提となる。
自動診断と手動診断は確認できる問題が異なる
脆弱性診断では、ツールによる自動診断と、セキュリティエンジニアによる手動診断を使い分ける。自動診断は、多数の検査パターンを効率よく適用し、同じ条件で繰り返し確認する用途に向く。一方、画面遷移や利用者の役割、操作の順序といった業務上の前提を悪用する問題は、定型的な検査だけでは判断しにくい。
OWASPの「Web Security Testing Guide」（WSTG）でも、処理回数の制限、ワークフローの迂回、想定外のファイル形式、支援や権限に関わる処理などを、ビジネスロジックの検査対象として挙げている。自動か手動かという二者択一ではなく、対象システムの構造と重要度に応じて、網羅性や再現性、業務文脈を踏まえた判断を組み合わせることだ。
リスク評価は「深刻度」と「自社への影響」を分けて考える
診断で問題が見つかると、次に必要になるのがリスク評価だ。BBSecでは、攻撃された場合の影響と、攻撃が成立する可能性を総合し、検出事項を5段階のリスクレベルに分類している。
レベル5：「緊急」は、攻撃時の影響が極めて大きく、攻撃の実行も容易な問題だ。レベル4：「重大」は、影響が大きく、一定の知識や技術があれば攻撃できる問題を指す。レベル3：「高」以下でも、外部公開の有無や扱うデータ、利用者の権限、他の問題点との組み合わせによって実際の対応優先度は変わる。
CVSS（Common Vulnerability Scoring System）は、ソフトウェア、ハードウェア、ファームウェアの脆弱性について、技術的な深刻度を共通の形式で伝えるための枠組みだ。CVSS v4.0には、脆弱性そのものの特性を表すBase、悪用状況など時間とともに変化する要素を扱うThreat、利用環境固有の条件を反映するEnvironmentalなどの指標群がある。
CVSSを管理する米国の非営利団体FIRSTの公式ガイドが明記している通り、CVSS Base Scoreは脆弱性の「深刻度」を表すものであり、それだけで組織固有の「リスク」を示すものではない。同じスコアでも、インターネットから直接到達できる基幹システムに存在する場合と、外部から分離された検証環境に存在する場合とでは、攻撃の現実性と事業への影響が異なる。
したがって、診断報告書のリスクレベルやCVSSスコアは、修正順を決める出発点として扱うべきだ。資産の重要度、外部からの到達可能性、保有する機密情報、攻撃コードや実悪用の有無、緩和策の有無、停止可能な時間、修正による業務影響を重ねて判断する必要がある。
高リスクの消し込みだけでは攻撃経路が残る
緊急性の高い問題を先に修正する方針は合理的だ。ただし、高リスクの指摘だけを消し込み、中・低リスクを恒常的に放置すれば、複数の問題点が組み合わさって攻撃経路を形成することがある。情報漏えい、不適切な設定、古いコンポーネントの利用などは、単独では直接的に被害へつながらなくても、攻撃者が攻撃対象の特定や次の攻撃手法の選択に利用し得る。
同じ種類の指摘が複数のシステムで繰り返される場合には、個別の修正だけでなく、設計基準や共通基盤、開発フレームワーク、レビュー手順、パッチ管理に共通の原因がないかを確認したい。診断結果をシステム単位で閉じず、横断的に集計することで、組織として修正すべき工程や管理方法が見えてくる。
管理者が見るべき指標も、検出件数だけではない。重要システムの高リスク問題を期限内に解消できたか、同種の指摘が再発していないか、診断対象から漏れている資産がないかを継続して点検する必要がある。件数の増減だけをKPIにすると、診断範囲を狭めるほど数値が良くなるという逆転も起こり得る。
診断結果を対策へ変える4つの判断
診断結果を実務へつなげるには、次の4つの判断を明確にする。
- 診断範囲：対象URLやAPI、アカウント、IPアドレスなど、今回確認した範囲
- 対応優先度：技術的な深刻度と自社環境を重ねて決める
- 修正期限と担当部署：誰がいつまでに直すかを決める
- 再診断による解消確認：修正後に問題が解消したかを確かめる
この4つがそろって初めて、一つの診断サイクルが閉じる。
診断報告書は、システムの安全を証明する合格証ではなく、限られた人員と予算をどこへ配分するかを決めるための資料だ。第2回では、この読み方を前提に、BBSecが2026年上半期に実施したWebアプリケーション診断とネットワーク診断の社内集計データから、全体傾向を確認する。
本連載は、BBSecの脆弱性診断実施データと診断現場の知見を基に構成している。
