CVSSスコアの読み方と脆弱性対応の優先度付け。基本値だけで判断しないために

脆弱性情報を見ていると、必ずと言っていいほど「CVSS 9.8」「深刻度 Critical」といった数値や評語が目に入ります。この数値は脆弱性の深刻さを共通の物差しで表したもので、対応の議論をするうえで欠かせない共通言語になっています。一方で、この数値の意味を取り違えると、対応の優先順位を大きく誤ります。

よくあるのは「CVSSが高い順に上から潰していく」という運用です。一見もっともらしく見えますが、CVSSの基本値（Base Score）は脆弱性そのものが持つ理論上の最悪ケースを表す指標であり、「いま実際に攻撃されているか」「自社の環境でどれだけ危ないか」を直接表してはいません。基本値だけで並べ替えると、緊急に塞ぐべき穴を後回しにし、実害の小さい高スコアに人手を吸い取られることが起こりえます。

この記事では、CVSS v3.1とv4.0の構成を原理から整理したうえで、基本値だけで判断しないための考え方と、KEVやEPSSといった実際の悪用情報を組み合わせた実務的な優先度付けの判断軸を解説します。対象は、脆弱性情報を受け取って自社の対応を判断する運用担当者やセキュリティ担当者です。

まずは早見表で全体像をつかむ#

細部に入る前に、登場する評価指標の役割を一覧で整理します。CVSSだけで完結させず、複数の情報源を組み合わせるのが現代の脆弱性管理の基本姿勢です。

CVSSの深刻度の評語と数値の対応は、v3.1・v4.0で共通です。執筆時点の定義は次のとおりです。

深刻度の評語とスコア範囲は FIRST の CVSS v4.0 仕様書に基づきます。同じ区分が v3.1 でも使われています。

CVSSとは何で、何を測っていないのか#

CVSS（Common Vulnerability Scoring System, 共通脆弱性評価システム）は、脆弱性の深刻度を0.0から10.0の数値で表す、ベンダー非依存のオープンな評価手法です。管理母体はFIRST（Forum of Incident Response and Security Teams）で、仕様の改善が継続的に行われています。共通の物差しがあることで、製品やベンダーをまたいで脆弱性の深刻さを同じ基準で比較し、関係者の間で共通の言葉で議論できるようになります。

ここで最も大切なのは、CVSSの基本値が「脆弱性そのものの性質」だけを評価している、という点です。基本値は、その脆弱性がどんな環境に置かれても変わらない固有の特性を、現実的な最悪ケースを想定して数値化します。逆に言えば、基本値には「いまその脆弱性が実際に攻撃に使われているか」「自社のその資産がどれだけ重要か」「すでに緩和策が入っているか」といった、時間や環境で変わる要素は含まれていません。

つまり、CVSSの基本値が高いことは「放置すれば理論上は深刻になりうる」ことを意味しますが、「いますぐ自社で危険」を意味するわけではありません。この区別が、優先度付けを誤らないための出発点になります。

CVSSの3つ（v4は4つ）の評価グループ#

CVSSのスコアは、複数の評価グループから構成されます。v3.1では基本評価基準・現状評価基準・環境評価基準の3つ、v4.0ではこれに補足（Supplemental）が加わった4つの構成です。ただし補足評価基準は脆弱性の追加的な文脈情報を伝えるためのもので、FIRSTの仕様上、最終的なCVSSスコアの数値には影響しません。多くの脆弱性情報サイトで表示されているのは、このうち基本評価基準だけで算出された値である点に注意してください。

基本評価基準（Base）#

脆弱性そのものの特性を評価する、時間や環境で変わらない部分です。攻撃のしやすさを表す指標（攻撃元区分、攻撃条件の複雑さ、必要な権限、利用者の関与など）と、成功したときの影響（機密性・完全性・可用性へのインパクト）から算出されます。脆弱性情報で単に「CVSS」と書かれているスコアは、ほぼこの基本値です。

現状/脅威評価基準（v3.1: Temporal / v4.0: Threat）#

時間とともに変化する要素を反映します。代表例が悪用コードの成熟度で、概念実証（PoC）止まりなのか、実際に攻撃に使える成熟したコードが出回っているのかで深刻度は大きく変わります。同じ脆弱性でも、悪用コードが公開された日を境に現実の危険度は跳ね上がります。この補正を入れることで、基本値が表す「理論上の最悪」を、いまの状況に近づけられます。

環境評価基準（Environmental）#

利用者自身が、自社の環境に合わせて補正するための基準です。たとえば、ある脆弱性の基本値が高くても、その資産がインターネットから隔離されていて重要度も低ければ、自社にとっての深刻度は下がります。逆に、基本値が中程度でも、それが基幹システムの根幹にあれば自社にとっては最優先になりえます。環境評価は、自社で評価して初めて意味を持つ部分です。

この声は、基本値だけで運用したときに陥りがちな典型です。基本値は出発点としては有用ですが、現状評価と環境評価による補正、そして後述する悪用情報との突き合わせがなければ、優先順位は現実とずれていきます。

v3.1からv4.0で何が変わったか#

CVSS v4.0は、基本評価の粒度を細かくし、実態をより正確に表せるよう設計されています。v3.1を前提に運用してきた組織が混乱しやすい主な変更点を整理します。

とくに重要なのが、v3.1のScope（スコープ）の廃止です。v3.1では、脆弱性の影響が脆弱なコンポーネントの境界を越えて別のコンポーネントに及ぶかどうかをScopeで表していましたが、判定が直感的でなく解釈が割れる原因になっていました。v4.0ではこれをやめ、影響を「脆弱なシステム自身への影響（VC/VI/VA）」と「後続システムへの影響（SC/SI/SA）」に明示的に分けています。これにより、たとえばハイパーバイザの脆弱性がゲスト側に波及するようなケースを、より素直に表現できます。

もう一つの実務的なポイントが、スコアの名称（ノメンクレーチャ）の導入です。どの評価グループまで使って算出したかを、CVSS-B（基本のみ）、CVSS-BT（基本＋脅威）、CVSS-BE（基本＋環境）、CVSS-BTE（基本＋脅威＋環境）と明示します。これは「いま見ているスコアがどこまで補正済みか」を取り違えないための仕組みです。脆弱性情報サイトで提示されるのはたいていCVSS-Bであり、これは補正前の出発点だと理解しておく必要があります。

OWASP Top 10のようなリスクのカテゴリ分類と、CVSSのような個別脆弱性の深刻度評価は役割が異なります。両者の関係を整理したい場合は

基本値だけで判断しないための実務#

ここからが本題です。CVSSの基本値は出発点として有用ですが、それだけで優先度を決めると現実とずれます。実務では、基本値に「実際に悪用されているか」と「自社でどれだけ危ないか」という2軸を掛け合わせて判断します。

KEV: 実際に悪用された脆弱性を最優先する#

CISAが公開するKEV（Known Exploited Vulnerabilities Catalog, 既知の悪用された脆弱性カタログ）は、実際に攻撃で悪用された証拠がある脆弱性を集めた一覧です。CVSSが「理論上どれだけ深刻か」を表すのに対し、KEVは「現実に使われたか」という、より直接的な危険信号を提供します。

実務上の判断はシンプルです。自社が使う製品の脆弱性がKEVに載っているなら、CVSSの数値にかかわらず最優先で対応を検討します。CVSSが中程度でも、実際に悪用されているなら放置すべきではありません。KEVは脆弱性管理の優先順位付けへの入力として使うことが意図されています。

EPSS: 悪用される確率で大量の脆弱性を絞り込む#

EPSS（Exploit Prediction Scoring System）は、ある脆弱性が今後30日以内に実際に悪用される確率を0から1の数値で表す、データ駆動の予測モデルです。FIRSTが提供しており、スコアは日次で更新されます。CVSSの基本値が静的なのに対し、EPSSは新しい脅威情報を反映して変わるのが特徴です。

EPSSが効くのは、対応すべき脆弱性が大量にあって手が回らない場面です。CVSSが高い脆弱性は世の中に膨大にありますが、その多くは実際には悪用されません。EPSSで悪用確率の高いものを上位に絞り込むことで、限られた人手を実際に危ないものへ集中できます。CVSSの深刻度とEPSSの悪用確率を組み合わせると、「深刻でかつ悪用されやすい」ものを浮かび上がらせられます。

SSVC: 意思決定そのものを構造化する#

数値スコアではなく、対応の意思決定を木構造で整理する手法としてSSVC（Stakeholder-Specific Vulnerability Categorization）もあります。悪用状況・技術的影響・自動化可能性・自組織での重要度といった要素から行動カテゴリを導く考え方で、CISAも独自の決定木を運用しています。CISAの決定木では Track（標準の更新サイクルで対応）、Track*（変化に注意して監視）、Attend（標準より早めの対応）、Act（できるだけ早く対応）の4つに振り分けます。スコアの大小に頼らず、組織の立場に応じた判断基準を明文化したいときに向いています。

ありがちな誤解と判断のコツ#

実務でつまずきやすい誤解をいくつか整理します。

第一に、「Critical（9.0以上）は常に最優先」という思い込みです。深刻度が高くても、悪用が観測されておらず、対象資産が隔離環境にあり、すでに緩和策が入っているなら、緊急度は下がります。深刻度（severity）と緊急度（urgency）は別物だと意識してください。

第二に、「スコアが同じなら対応も同じ」という誤解です。同じCVSS 7.5でも、外部公開サーバの認証回避と、内部限定ツールの情報漏えいでは、自社にとっての意味がまったく違います。スコアは比較の起点にはなりますが、最終判断には自社の文脈が要ります。

第三に、「KEVに載っていなければ安全」という早合点です。KEVは悪用が確認・公表されたものの一覧であり、まだ観測・公表されていない悪用は当然載りません。KEVは強い加点材料ですが、載っていないことを安全の根拠にはできません。

これらに共通するのは、単一の数値を絶対視せず、複数の情報源と自社の文脈を重ねて判断する姿勢です。認証まわりの脆弱性のように、緩和策の有無が緊急度を大きく左右する領域もあります。多要素認証など防御層の整備状況も判断材料になるため、

よくある質問#

まとめ#

CVSSは脆弱性の深刻度を共通の物差しで表す優れた仕組みですが、基本値だけで優先順位を決めると現実とずれます。基本値を出発点とし、現状/環境評価による補正、KEVやEPSSといった実際の悪用情報、そして自社の資産の文脈を重ねて初めて、人手を本当に危ないものへ集中できます。数値は判断を助ける材料であって、判断そのものを肩代わりするものではない、という姿勢が実務では最も重要です。