CVSS（共通脆弱性評価システム）は、脆弱性の深刻度を0.0〜10.0のスコアで表す世界共通の評価手法です。公開される脆弱性情報にはほぼ必ずCVSSスコアが添えられており、対応の優先順位を決める重要な手がかりになります。

この記事では、スコア5段階の見方や評価基準、最新版v4.0の変更点、ベクトル文字列の読み方、そして自社の脆弱性対応に活かす方法をわかりやすく解説します。

CVSSとは

脆弱性の深刻度を0.0〜10.0で表す共通のものさし

CVSS（Common Vulnerability Scoring System）は、情報セキュリティにおける脆弱性の深刻度を定量的に評価し、スコアとして示すためのフレームワークです。
脆弱性の深刻度を一貫した方法で測定・評価できるため、セキュリティ管理者や企業・組織は脆弱性の影響を把握し、優先度に応じて対策を講じることができます。

CVSSスコアは0.0から10.0の範囲で表され、数値が高いほど深刻度が高いことを示します。特定のベンダーに依存しない共通の基準で評価されるため、異なる製品の脆弱性でも同じものさしで比べられる点が大きな特徴です。

誕生の経緯と管理団体FIRST

CVSSは、米国の国家インフラストラクチャ諮問委員会（NIAC）のプロジェクトとして原案が作られました。それまでは製品ベンダーやセキュリティ組織がそれぞれ独自の基準で深刻度を示しており、同じ脆弱性でも評価がばらばらだったことが背景にあります。

現在は、インシデント対応チームの国際的なフォーラムであるFIRST（Forum of Incident Response and Security Teams）が管理しています。
仕様の改訂は、FIRST内のCVSS-SIG（Special Interest Group）が担っています。これまでにv2、v3.0、v3.1と改訂が重ねられ、2023年11月には最新版のv4.0が公開されました。

CVE・NVD・JVNとの関係

CVSSとあわせて目にすることが多いのが、CVEやNVD、JVNです。それぞれの役割は次のとおりです。

CVE番号で脆弱性を特定し、CVSSスコアで深刻度を確認するという組み合わせで使われるのが一般的です。

CVSSスコア5段階の見方

深刻度5段階と対応の目安

CVSSスコアは、数値の範囲によって5段階の深刻度に分類されます。日本ではJVNなどで次の名称が使われています。

表の対応の目安は、一般的な考え方の一例です。実際の優先度は自社の環境や悪用の状況によって変わるため、後述する方法で見直すことが大切です。

同じ脆弱性でもスコアが異なる理由

同じCVE番号の脆弱性でも、情報源によってスコアが異なることがあります。主な理由は、評価に使ったCVSSのバージョンの違い、評価した組織の違い、そしてスコアに含めた評価基準の違いです。

たとえば、v3.1とv4.0では評価項目や計算方法が異なるため、同じ脆弱性でも数値が変わります。また、製品ベンダーとNVDなどの第三者機関がそれぞれの判断で評価した結果が、並んで公開されることもあります。

スコアを見るときの確認ポイント

数字だけを見て判断する前に、次の3点を確認しておくと読み違いを防げます。

どのバージョンで評価されたか

スコアの近くには「CVSS v3.1」「CVSS v4.0」といったバージョンが記載されています。バージョンが異なるスコア同士を単純に比べることはできないため、比較するときはバージョンをそろえて見ることが基本です。

どの評価基準を使ったスコアか

公開されているスコアの多くは、脆弱性そのものの特性だけを評価した基本スコアです。悪用の状況や自社の環境はまだ反映されていないため、自社にとっての深刻度とは別のものと考えましょう。

どの組織が評価したか

評価した組織によって、判断が分かれる場合があります。製品ベンダーと第三者機関の評価が異なるときは、それぞれの根拠となる評価項目を見比べると、違いが生まれた理由がわかります。

CVSS v3.1の3つの評価基準

基本評価基準

基本評価基準（Base Metrics）は、脆弱性の固有の特性を評価するもので、脆弱性がどのように悪用される可能性があるか、どれだけ影響を与えるかを示します。時間の経過や利用環境によって変化しない評価で、主に製品ベンダーや脆弱性情報を公開する組織が評価します。
現在広く使われているv3.1では、次の8項目で評価します。

攻撃元区分（AV）

脆弱性を悪用するために必要な、攻撃者の物理的な位置やアクセス手段を評価します。
ネットワーク（Network）、隣接ネットワーク（Adjacent）、ローカル（Local）、物理（Physical）の4つに分類され、ネットワーク越しに攻撃できる脆弱性ほど深刻度が高くなります。

攻撃条件の複雑さ（AC）

脆弱性を悪用するための条件の複雑さや、特殊な状況が必要かどうかを評価します。評価値は「低」と「高」の2つで、複雑さが低い、つまり攻撃しやすいほど深刻度が高くなります。

必要な特権レベル（PR）

脆弱性を悪用するために攻撃者が必要とする権限のレベルを評価します。評価値は「不要」「低」「高」の3つで、権限が不要な場合ほど深刻な脆弱性として評価されます。

ユーザー関与レベル（UI）

攻撃を成功させるために、被害者となる利用者の操作が必要かどうかを評価します。評価値は「不要」と「要」の2つで、利用者の関与が不要な場合ほど深刻度が高くなります。

影響の想定範囲（S）

脆弱性を悪用された影響が、脆弱性のあるコンポーネントの外にまで広がるかどうかを評価します。評価値は「変更なし」と「変更あり」の2つで、ほかのコンポーネントにまで影響が及ぶ場合は「変更あり」となり、スコアが高くなります。

機密性・完全性・可用性への影響（C・I・A）

脆弱性を悪用された場合に、情報セキュリティの3要素がどれだけ損なわれるかを評価します。機密性は情報漏えい、完全性はデータの改ざんや不正な変更、可用性はサービスの停止やリソースの制限への影響を表し、それぞれ「高」「低」「なし」で評価します。

現状評価基準

現状評価基準（Temporal Metrics）は、脆弱性の現在の状態を評価します。時間とともに変化する要素を反映して基本スコアを調整する仕組みで、v3.1では基本スコアを据え置くか下げる方向に働くため、現状スコアが基本スコアを上回ることはありません。
次の3項目で構成されます。

攻撃される可能性（E）

脆弱性を悪用するためのエクスプロイトコードがどれだけ出回り、実用的な状態にあるかを評価します。攻撃コードが公開されたり、実際の攻撃に使われたりすると、評価は高くなります。

利用可能な対策のレベル（RL）

脆弱性に対する修正の提供状況を評価します。製品ベンダーから正式なパッチが提供されているか、暫定的な回避策しかないかなどが考慮されます。

脆弱性情報の信頼性（RC）

脆弱性に関する情報がどれだけ信頼できるかを評価します。製品ベンダーが脆弱性の存在を認めている場合などは、信頼性が高いと評価されます。

環境評価基準

環境評価基準（Environmental Metrics）は、組織にとって脆弱性がどの程度重要であるかを評価します。同じ脆弱性でも利用する組織の環境によって結果が変わるため、製品の利用者が自ら評価することが想定されています。

対象システムのセキュリティ要求度（CR・IR・AR）

機密性、完全性、可用性に対する組織のセキュリティ要件を考慮してスコアを調整します。たとえば、顧客情報を扱うシステムでは機密性の要求度を「高」に、停止が許されない基幹システムでは可用性の要求度を「高」に設定します。

環境に合わせた基本評価の再評価

自社の環境に合わせて、基本評価基準の各項目を評価し直すこともできます。たとえば、外部から到達できないネットワークに置かれたシステムであれば攻撃元区分を見直すなど、導入済みの緩和策を反映した評価が可能です。

CVSS v4.0の主な変更点

v3.1とv4.0の違いを一覧で確認

v4.0は、v3.1で指摘されていた課題を踏まえ、評価をより細かく、現実の状況に即したものにすることを目指した改訂です。主な違いは次のとおりです。

なお、深刻度5段階の区分とスコアの範囲は、v4.0でも変わっていません。

攻撃の実行条件（AT）の新設

v4.0では、攻撃を成功させるために対象システム側に特定の条件が必要かどうかを評価する「攻撃の実行条件（AT：Attack Requirements）」が新設されました。
たとえば、特定の設定が有効な場合にしか成立しない脆弱性や、処理のタイミングを狙う必要がある脆弱性は、条件ありとして評価されます。

v3.1では、こうした条件も攻撃条件の複雑さ（AC）にまとめて評価していました。v4.0では、防御機能の回避など攻撃者側の難しさをAC、システム側の条件をATと分けて評価することで、深刻度をより正確に表せるようになりました。

スコープの廃止と後続システムへの影響

v3.1の影響の想定範囲（S）は、評価者によって判断がぶれやすいという課題がありました。
v4.0ではこの項目が廃止され、脆弱性が存在するシステム（Vulnerable System）への影響と、その先にある後続システム（Subsequent System）への影響を、それぞれ機密性・完全性・可用性の3項目で評価する方式に変わりました。

さらに環境評価基準では、後続システムの完全性と可用性への影響に「安全性（Safety）」という評価値が加わりました。これにより、産業制御システムやIoT機器などで、人の身体や生命に危害が及ぶ可能性まで表せるようになっています。

ユーザー関与レベルの3段階化

ユーザー関与レベル（UI）は、v3.1の「不要」「要」の2段階から、「なし（None）」「受動的（Passive）」「能動的（Active）」の3段階に細分化されました。
受動的は、罠が仕掛けられたページを閲覧するなど、利用者が意識的に操作しなくても成立する関与を指します。能動的は、ファイルを開く、リンクをクリックするなど、利用者の明確な操作が必要な関与です。

現状評価基準から脅威評価基準へ

v3.1の現状評価基準は、最終的なスコアへの影響が小さいことが課題とされていました。v4.0では名称が「脅威評価基準（Threat Metrics）」に変わり、評価項目も「攻撃される可能性（E：Exploit Maturity）」の1項目に集約されました。

評価値は、実際に攻撃が報告されている「Attacked」、概念実証コードが公開されている「POC」、どちらも報告されていない「Unreported」などです。
未評価の場合は最も深刻な状態を想定して計算されるため、脅威評価を加えるとスコアは据え置きか下がる方向に働きます。

補助評価基準とスコア表記（CVSS-B・BT・BE・BTE）

v4.0では、スコアの計算には使われない「補助評価基準（Supplemental Metrics）」が新設されました。攻撃を自動化できるか、人の安全に影響するか、攻撃後に復旧できるかといった、対応を判断するうえで役立つ補足情報を伝えるためのものです。

あわせて、どの評価基準を使ったスコアなのかを明示する表記も導入されました。

CVSSベクトル文字列の読み方

ベクトル文字列とは

ベクトル文字列は、CVSSスコアを算出するときに選んだ評価値を、決まった略号で1行にまとめた文字列です。NVDやJVNの脆弱性情報では、スコアとあわせて記載されています。

スコアは結果の数字にすぎませんが、ベクトル文字列を見れば、なぜそのスコアになったのかがわかります。スコアだけでなくベクトル文字列まで確認すると、自社の環境に当てはまるかどうかを具体的に判断できます。

v3.1のベクトル文字列を読み解く

ベクトル文字列は、「項目の略号:評価値の略号」をスラッシュで区切って並べた形をしています。図の例「CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H」は、次のように読み解けます。

先頭の「CVSS:3.1」は、v3.1で評価したことを示します。続く「AV:N/AC:L/PR:N/UI:N」は、ネットワーク経由で、特別な条件も権限も利用者の操作も必要とせずに攻撃できることを表しています。
「S:U」は影響範囲が変わらないこと、「C:H/I:H/A:H」は機密性・完全性・可用性のすべてに大きな影響が出ることを意味します。

この組み合わせの基本値は9.8で、深刻度は「緊急」です。外部から誰でも攻撃でき、影響も大きい脆弱性の典型的なパターンといえます。
ベクトル文字列を読めるようになると、「AV:N」の脆弱性でも自社では該当システムを外部に公開していない、といった判断がしやすくなります。

v4.0のベクトル文字列で増えた項目

v4.0のベクトル文字列は「CVSS:4.0」から始まり、v3.1にはなかった項目が加わります。代表的なものは、攻撃の実行条件を表す「AT」、脆弱なシステムへの影響を表す「VC・VI・VA」、後続システムへの影響を表す「SC・SI・SA」です。

たとえば「CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N」は、ネットワーク経由で条件なしに攻撃でき、脆弱なシステムに大きな影響がある一方、後続システムには影響しないことを示します。
v4.0では脅威評価基準の「E」や補助評価基準の項目が続くこともあるため、末尾まで確認しましょう。

CVSSスコアの算出方法

計算ツールを使った算出の手順

CVSSスコアの計算式はFIRSTが公開している仕様書で定められていますが、実務では計算ツールを使うのが一般的です。FIRSTやNVDのWebサイトのほか、日本語で使えるものとしてJVNでも計算ツールが公開されています。

算出の流れとしては、まず使用するバージョンの計算ツールを開き、評価項目ごとに当てはまる評価値を選択します。すべての項目を選ぶとスコアとベクトル文字列が自動で表示されるため、その結果を記録しておきます。
既存のベクトル文字列を入力して、スコアを再現できるツールもあります。

評価項目の選択で迷ったときの考え方

評価値の選択に迷った場合は、仕様書の定義に立ち返るとともに、NVDやJVNで公開されている似た種類の脆弱性の評価例を参考にすると判断しやすくなります。

また、迷った理由と最終的に選んだ根拠を記録しておくことも大切です。後から見直したときや担当者が変わったときにも、同じ基準で評価を続けられます。

CVSSを脆弱性対応に活かす方法

CVSSの主な利用場面

CVSSは、組織のさまざまな場面で共通の判断材料として使われています。代表的な利用場面は次の3つです。

脆弱性管理の優先順位付け

CVSSスコアを用いて、組織のネットワークやシステムにおける脆弱性を管理し、リスクの高い脆弱性を優先的に対策することができます。日々公開される多くの脆弱性すべてに同時に対応するのは難しいため、限られた人員や時間を振り分ける基準として役立ちます。

セキュリティ監査

CVSSを利用して脆弱性の深刻度を評価し、セキュリティ対策が十分かどうかを監査することが可能です。深刻度の高い脆弱性が放置されていないかを確認する指標として使えます。

ベンダーと利用者のコミュニケーション

CVSSスコアを基に、ベンダーが提供するパッチや対策の優先度を利用者に伝えることで、効果的なセキュリティ対策を講じることができます。共通の基準があることで、ベンダー、セキュリティ担当者、経営層の間でも深刻度の認識をそろえやすくなります。

公開スコアを自社向けに見直す手順

NVDやベンダーが公開するスコアは、多くの場合、脆弱性そのものを評価した基本スコア（CVSS-B）です。そのまま優先度を決めるのではなく、次の流れで自社向けに見直すと、より実態に合った判断ができます。

最初に、該当する製品やバージョンが自社で使われているかを確認します。資産台帳などで該当がなければ、その脆弱性への対応は不要です。

次に、脅威評価を加えます。攻撃コードの公開状況はExploit Databaseなどで、実際の悪用の有無はKEVなどで確認し、悪用の状況を評価に反映させます。

最後に、環境評価を加えます。対象システムの重要度や外部からの到達性、導入済みの緩和策を反映させることで、自社にとっての深刻度（CVSS-BTE）が得られます。公開スコアはあくまで出発点であり、自社の状況を反映させて初めて対応の優先度が決まります。

社内ルールに対応期限を組み込む

CVSSを継続的に活用するには、深刻度ごとの対応期限を社内ルールとして決めておくことが効果的です。たとえば「緊急は最優先で対応し、重要は計画的に対応する」のように基準を決めておけば、担当者によって判断がぶれるのを防げます。

期限の長さは、組織の規模や体制、システムの特性によって適切な水準が異なります。KEVに掲載された脆弱性はスコアにかかわらず優先する、といった例外ルールもあわせて定めておくと運用しやすくなります。

CVSSだけに頼らないための補完指標

CVSSは「リスク」そのものではない

CVSSが示すのは、脆弱性が悪用された場合にどれほど深刻な影響があり得るかという「深刻度」です。実際に攻撃される可能性や、自社にとっての被害の大きさまでを含む「リスク」とは異なります。
CVSSを管理するFIRSTも、CVSSのスコアだけでリスク評価を代替すべきではないとしています。

スコアが高いことと、実際に攻撃される可能性が高いことは必ずしも一致しません。そこで、次のような指標を組み合わせて判断を補います。

EPSS：悪用される確率を予測する

EPSS（Exploit Prediction Scoring System）は、脆弱性が今後30日以内に悪用される確率を予測する指標で、CVSSと同じくFIRSTが提供しています。
0〜100%の確率で示されるため、CVSSの深刻度と組み合わせることで、深刻で、かつ悪用されやすい脆弱性を見つけやすくなります。

KEV：実際に悪用された脆弱性を確認する

KEV（Known Exploited Vulnerabilities）カタログは、米国CISAが公開している、実際に悪用が確認された脆弱性の一覧です。すでに攻撃に使われている事実があるため、CVSSスコアの高低にかかわらず優先して対応すべき根拠になります。

SSVC：意思決定の流れで判断する

SSVC（Stakeholder-Specific Vulnerability Categorization）は、スコアを計算するのではなく、悪用の状況や影響の大きさといった問いに順に答えていくことで対応方針を決める手法です。
米国カーネギーメロン大学のCERT/CCなどが提唱し、CISAも活用しています。

Exploit Database：悪用コードの公開状況を確認する

Exploit Databaseは、既知の脆弱性に対するエクスプロイトやPoCを集めた公開データベースです。脆弱性を突くコードが公開されているかを確認できるため、v4.0の脅威評価やv3.1の現状評価を判断する材料として役立ちます。

これらの指標は、それぞれ得意とする情報が異なります。CVSSで深刻度を確認し、EPSSやKEV、Exploit Databaseで悪用の可能性や実績を確かめるなど、組み合わせて判断することが重要です。

CVSSに関するよくある質問

Q. CVSSとCVEの違いは何ですか？

CVEは脆弱性を特定するための識別番号で、CVSSはその脆弱性の深刻度を表すスコアです。CVE番号で脆弱性を特定し、CVSSスコアで深刻度を確認するという形で、セットで使われます。

Q. v3.1とv4.0のどちらのスコアを見ればよいですか？

現在は移行期にあたり、v3.1とv4.0のスコアが併記されていたり、どちらか一方だけが公開されていたりします。どちらを見る場合も、社内で比較するときはバージョンをそろえ、ベクトル文字列で評価の中身を確認することが大切です。

Q. CVSSスコアは誰が決めていますか？

主に製品ベンダーや、NVD、JVNなどの脆弱性情報を公開する組織が、FIRSTの仕様に基づいて基本スコアを評価しています。脅威評価や環境評価は、製品を利用する組織が自ら行うことが想定されています。

Q. スコアが低い脆弱性は対応しなくてもよいですか？

スコアが低くても、実際に悪用されている場合や、自社の重要なシステムに関係する場合は優先度が上がります。KEVへの掲載状況や自社の環境を確認したうえで判断しましょう。

Q. CVSSスコアはどこで確認できますか？

NVDやJVN iPediaなどの脆弱性データベースのほか、製品ベンダーのセキュリティアドバイザリで確認できます。CVE番号で検索すると、該当する脆弱性のスコアとベクトル文字列を確認できます。

まとめ

CVSSは、脆弱性の深刻度を0.0〜10.0のスコアと5段階の区分で表す世界共通の評価手法です。スコアを見るときは、バージョンや評価基準、評価した組織を確認し、ベクトル文字列で評価の中身まで読み取ることが大切です。

公開スコアに脅威評価と環境評価を加え、EPSSやKEVなどの補完指標と組み合わせることで、自社が優先すべき脆弱性を見極めやすくなります。

書籍「セキュリティ対策の基礎知識」
メルマガ登録でプレゼント！

セキュリティ対策で何をして良いかわからない
企業の情シス部門の方必見！

メルマガ登録はこちらから