CVSSとは？スコアの見方と評価基準をわかりやすく解説
※本記事は2026年7月31日に、CVSS v4.0の内容に基づき情報を更新しています。
世の中では毎日大量の脆弱性が発見されています。
とくに生成AIによってソフトウェアの脆弱性が発見されるペースが上がっている今、自組織で使用しているソフトウェアで発見された脆弱性にどのように対処すればよいのでしょうか？
本記事では、そんなときの指標として役立つCVSSをそのスコアの付け方も含めて解説していきます。
CVSS（Common Vulnerability Scoring System）とは？
CVSS（Common Vulnerability Scoring System）は、ベンダーに依存しない国際的な脆弱性深刻度評価の基準です。
現在はFIRSTが管理しており、本記事執筆時点では2023年11月にリリースされたバージョン4.0が最新版となっています。
この記事ではCVSS v4.0の仕組みを「基本評価基準」を中心にわかりやすく解説します。
CVSSの中身
CVSSで脆弱性の深刻度を評価する際には、4つのトピックに関してその脆弱性を分析する必要があります。
その4つの基準とは「基本評価基準（Base）」、「脅威評価基準（Threat）」、「環境評価基準（Environmental）」、「補助評価基準（Supplemental）」になります。
ただし、補助評価基準は最終的なCVSSのスコアに影響を与えません。
CVSSのスコアは基本評価基準、脅威評価基準、環境評価基準の評価をもとに、最終的に10点満点で計算されます。
実際に、各基準の分析結果からCVSSのスコアを計算することはかなり難しいので、たとえばFIRSTのサイト(https://www.first.org/cvss/calculator/4.0)にある計算機を使うのがいいでしょう。
CVSSではスコアから、その脆弱性の重大性を5つのクラスに分けています。
ここでの重大性は、その脆弱性に対する対応の要求度合いとみて良いものになっています。
したがって、緊急と評価される脆弱性が見つかった場合には、緊急で対応をすることが望ましい、ということになります。
それでは、CVSSのスコアを計算するために必要な3つの基準を順番に見ていきましょう。
基本評価基準
基本評価基準はその脆弱性自体の特性を表す基準です。
評価項目は全部で11項目ありますが、攻撃の難易度と攻撃がシステムに与える影響の2つに大別されます。
ひとつ前のバージョンのCVSS v3.1では各項目のスコアは分析する側の人間の裁量に任せられていましたが、CVSS v4.0では明確に基準が設けられるようになりました。
まず攻撃の難易度に関する項目を見ていきましょう。
攻撃の難易度に関する項目は5つに細分されています。
● 攻撃元区分: 攻撃者がどこから脆弱なシステムに攻撃を行えるかを評価します。
– (N) ネットワークを介した攻撃が可能：これは、インターネットを通じた攻撃が可能であるとも言い換えられます。
– (A) 攻撃対象に隣接したネットワークから攻撃が可能：たとえば、攻撃者のPCが脆弱なシステムとローカルネットワークで接続している必要がある場合は、このレベルに該当します。
– (L) 攻撃対象となるシステムのローカル環境から攻撃が可能：たとえば、脆弱性があるソフトウェアが動作しているPCを直接操作する必要がある場合は、このレベルに該当します。
– (P) 攻撃対象となるシステムに物理アクセスできる時に攻撃が可能：USBを接続するなど、実際に攻撃者自身が攻撃対象となるコンピューターに触れる必要がある場合を指します。
[攻撃経路の例]
● 攻撃の複雑性: 攻撃を成功させるために何らかのセキュリティ機構の回避が必要であるかを評価します。
– (L) 複雑性は低い
– (H) 複雑性は高い: ASLRやDEPといったセキュリティ機構の回避や、本来非公開であるアプリケーションのAPIキーや認証情報が必要な場合は、このレベルに該当します。
● 攻撃の実行条件: 攻撃が成功するために、特定の前提条件が必要かを評価します。
– (N) 実行条件は存在しない
– (P) 実行条件が存在する: 中間者攻撃、レースコンディションや特定の設定が必要である場合は、このレベルに該当します。
● 必要な特権レベル: 攻撃を実施するために必要な権限の高さを評価します。
– (N) 一切の権限が必要でない: そのシステムのユーザーアカウントを持たずに攻撃が実行できる場合は、このレベルに該当します。
– (L) 操作が制限された権限が必要: 一般のユーザーアカウントを持っていれば、管理者権限でなくても攻撃が実行できる場合は、このレベルに該当します。
– (H) 高い権限が必要: 管理者権限など、システムに対する重要な操作を行える権限が必要であることを意味しています。
● ユーザー関与レベル: 攻撃に攻撃者以外の人物の操作が必要であるかを評価します。
– (N) 他ユーザーの関与が必要ない
– (P) 他ユーザーの受動的な関与が必要: たとえば、Webアプリケーションにアクセスすることや、プログラムを実行するなど、日常的に行うことが考えられる操作が要求される場合は、このレベルに該当します。
– (A) 他ユーザーの能動的な関与が必要: たとえば、特殊なリクエストをWebアプリケーションに送信することや、特定のディレクトリにファイルを保存することなど、日常的には行うことが想定されていない操作をユーザーにしてもらう必要がある場合は、このレベルに該当します。
つづいて、攻撃がシステムに与える影響に関する評価項目を見ていきます。
これらの項目では、機密性・完全性・可用性という情報セキュリティの3大要素がどの程度損なわれるかを、システム自身とシステムに関連するサブシステムについて評価を行います。
[情報セキュリティの三台要素]
● 脆弱なシステムの機密性への影響:「どれだけ情報が漏れてしまうか」を評価します。
– (N) 機密性は失われない
– (L) 部分的に失われる（例: 一部の情報だけ見えてしまう、攻撃者が完全にコントロールできない）
– (H) すべて失われる（例: 攻撃者が任意の機密情報を自由に取得できる）
● 脆弱なシステムの完全性への影響: 「どれだけ情報が書き換えられてしまうか」を評価します。
– (N) 完全性は失われない
– (L) 部分的に失われる（例: 一部の情報だけ書き換えられてしまう、攻撃者が完全にコントロールできない）
– (H) すべての完全性が失われる（例: 攻撃者が任意の情報を自由に書き換えることができる）
● 脆弱なシステムの可用性への影響: 「どれだけシステムが利用できなくされてしまうか」を評価します。
– (N) 可用性は失われない
– (L) 部分的に可用性が失われる（例：システムにラグが発生する、操作に失敗することが多くなる）
– (H) 完全に可用性が失われる（例：システムにアクセスできなくなる、重要な機能が使用不可能になる）
また、攻撃を受けたシステムに関連するシステムの機密性・完全性・可用性が損なわれる度合いについても評価を行います。
たとえば、脆弱なシステムがWebアプリケーションであった場合には、関連するシステムとはWebアプリケーションシステムを稼働させているサーバーなどが該当します。
それぞれ評価の基準は、脆弱性存在するシステムと同様であるため、以下ではWebアプリケーションとHTTPサーバーの関係を例に、関連するシステムの機密性・完全性・可用性について説明します。
– 機密性: 関連するシステムの機密情報とは、サーバーに保存されたファイルなどが該当します。
これらの情報が外部に漏洩してはいけません。ただし、本来、HTTPサーバーを稼働させているユーザーから閲覧できるものについては、上記の「脆弱なシステムの機密性への影響」に包含されます。
関連するシステムへの影響とは、権限昇格などを伴い、たとえばrootユーザーしか閲覧できないファイルが閲覧できる場合などが該当します。
– 完全性: サーバーに保存されたファイルが書き換えられてはいけません。また、サーバーのOSのユーザーアカウントの追加、削除やパスワード変更も行われてはいけません。こちらも同じく、主に権限昇格を伴う完全性の侵害が該当します。
– 可用性: サーバーにアクセスすることや、サーバー上で正常な操作が行える必要があります。サーバーのメモリやCPU使用率を逼迫させられ、サーバーが正常に動作しなくなる場合や、強制的にシャットダウンさせられてしまう場合などは可用性が損なわれたと判断します。評価は脆弱性があるシステムへの影響と同じく3段階です。
● 関連するシステムの機密性への影響: 脆弱なシステムに関連するシステムが保有する機密情報が閲覧できるようになってしまう度合いを評価します。
– (N) 機密性は失われない。
– (L) 部分的に機密性が失われる。
– (H) すべての機密性が失われる。
● 関連するシステムの完全性への影響: 脆弱なシステムに関連するシステムの情報に変更が加えられてしまう度合いを評価します。
– (N) 完全性は失われない。
– (L) 部分的に完全性が失われる。
– (H) すべての完全性が失われる。
● 関連するシステムの可用性への影響: 脆弱なシステムに関連するシステムが利用できなくなる度合いを評価します。
– (N) 可用性は失われない。
– (L) 部分的に可用性が失われる。
– (H) 完全に可用性が失われる。
以上の11項目をもとに、攻撃の容易さと攻撃がシステムに与える影響を総合的に評価した結果が、CVSSの基本評価基準になります。この基準値は、脆弱性自体の特性を表す値であって、その脆弱なシステムを取り巻く環境に依存しない不変の値とされます。
たとえば、MITREが採番するCVEという脆弱性の識別子に対して、NVDがCVSSの基本評価基準によるスコアを付与しています。
しかし、基本評価基準は脆弱性の危険度を正確に表しているとは言い難い側面があります。
次のようなケースを考えてみましょう。
脆弱性Aはインターネットから攻撃が可能である基本評価基準で9.5をつけられた危険な脆弱性ですが、いまだ実際に悪用された例は確認されていないとしましょう。
一方で、脆弱性Bは基本評価基準で7.0をつけられた脆弱性ですが、現在進行形で世界中でこの脆弱性を悪用した攻撃が観測されているとします。
このとき、本当に緊急で対策をするべき脆弱性はどちらでしょうか？
確かに、脆弱性自体の危険度は脆弱性Aの方が高いですが何らかの理由で、直ちに攻撃者が攻撃に利用することは困難である可能性もあります。
しかし、一方で、脆弱性Bはすでに悪用が始まっている脆弱性ですから、自社のシステムが攻撃の被害を被るリスクはすでに顕在化しています。
また、脆弱性Aはインターネットから攻撃が可能であるとしましたが、脆弱性Aを持つシステムをインターネットと隔離されたローカルネットワークでのみ利用している場合には、インターネットから攻撃が可能であるという特性はあまり意味を持ちません。
システムがインターネットと通じていないため、基本評価基準における攻撃元区分は実質的に(A)に相当しています。
このように世の中の状況やシステムを稼働させている環境によって脆弱性の本当の危険度は変化する場合があります。CVSSでは各組織が運用しているシステムにおける現在の脆弱性の危険度を測るために、以下の2つの基準を使用します。
脅威評価基準
その脆弱性が実際にどれだけ悪用されているか・悪用されやすいかを評価します。
v4.0では「攻撃の成熟度」という指標で、以下の3段階で評価します。
– (U) 概念実証コードが入手できず、攻撃も観測されていない
– (P) 攻撃を可能とする概念実証コードが一般に公開されている
– (A) すでに攻撃に利用されている事例が確認されている
概念実証コードとは、脆弱性が存在することを証明するためのスクリプトのことを指します。
したがって、概念実証コードが一般に公開されている脆弱性については、すべての人がその脆弱性を狙った攻撃を行うことができる状態になっていると言えます。
つまり、そのような脆弱性が残ったシステムは、差し迫った脅威に直面していると評価されることになります。
この基準については、公開されていなかった概念実証コードが一般公開されるようになるなど、世の中の変化によって変動することがあるということに注意する必要があります。
環境評価基準
脆弱なシステムを利用している環境において、基本評価基準と同じ項目について再評価を行うとともに、その環境における機密性・完全性・可用性の重要度をそれぞれ3段階で評価します。
たとえば、あるシステムにネットワーク越しによる攻撃が可能な脆弱性が発見されたとしても、そのシステムをローカルネットワークでのみ利用している会社にとっては、ネットワーク越しの攻撃は事実上不可能になります。
そのため、この会社にとってこの脆弱性の基本評価基準における「攻撃元区分」は（A）と同等である、と考えて良いため、基本評価基準のスコアに修正を加えることが脆弱性の深刻度の評価として正確になります。
[外部からの攻撃が不可能]
また、あるデータベース管理システムの機密性を侵害する脆弱性が発見されたとしても、ある企業ではそのデータベース管理システムに保存している情報のすべてが公開情報であった場合、その企業にとってデータベース管理システムに保存している情報の機密性はまったく重要でないということになります。
逆に言えば、一部でも機密性が失われてはならないような情報を保存しているデータベース管理システムについては、攻撃による機密性への影響は重く評価しなければなりません。
このように、脆弱性を保有しているシステムを稼働させている環境によって、基本評価基準を補正するための基準が環境評価基準になります。
CVSSを使って脆弱性の危険度を見定めよう
今回は、CVSSの計算方法について紹介しました。
CVSSは非常に強力な指標ですが、基本評価基準のスコアだけを見て判断するのは危険です。
脅威評価基準や環境評価基準を組み合わせることで、初めて「自社にとっての本当の危険度」が見えてきます。
また、脅威評価基準は時間とともに変化します。昨日まで(U)だった脆弱性が今日、概念実証コードが公開されて(P)になることもあります。
CVSS計算機を活用しつつ、「この脆弱性は自社で今、本当に優先して対応すべきか、本当に対応しなくてよいのか」を判断する材料にしてください。
