CVSS

デジタル大辞泉

シー‐ブイ‐エス‐エス【CVSS】

読み方：しーぶいえすえす

《common vulnerability scoring system》ソフトウエアやコンピューターシステムの脆弱(ぜいじゃく)性の深刻さについての、共通の評価基準。コンピューターセキュリティーに関する国際団体FIRST(ファースト)が策定。開発業者などに依存しない、汎用的な評価手法となっている。共通脆弱性評価システム。

ウィキペディア

共通脆弱性評価システム

出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2026/02/26 10:02 UTC 版)

共通脆弱性評価システム

ステータス	Active
初版	2005年2月 (2005-02)
最新版	4.0
組織	Forum of Incident Response and Security Teams
ドメイン	情報セキュリティ
略称	CVSS
ウェブサイト	www.first.org/cvss/

共通脆弱性評価システム（きょうつうぜいじゃくせいひょうかシステム、英: Common Vulnerability Scoring System、略:CVSS）は、コンピュータシステムにおけるセキュリティ脆弱性の深刻度を評価するためのオープンなフレームワークである。スコアは、攻撃の容易さや影響度を近似する複数の評価基準に基づく計算式によって算出される。深刻度は0から10の範囲で割り当てられ、10が最も深刻であることを示す。多くの場合は深刻度の判断にCVSSの基本評価基準のみを使用するが、緩和策の利用可能性や組織内での脆弱なシステムの普及度合いをそれぞれ考慮するための現状評価基準および環境評価基準も存在する。

現在のバージョンのCVSS（CVSSv4.0）は、2023年11月にリリースされた。

CVSSは本来、パッチ管理の優先順位付けの手法として使用されることを意図したものではないが、実際にはそのように利用されることが多い。より効果的なアプローチは、現実世界で悪用される可能性に基づいて修正作業の優先順位付けを支援する、悪用予測評価システム（Exploit Prediction Scoring System、EPSS）などの予測モデルとCVSSを統合することである。

歴史

2003年から2004年にかけての国家インフラストラクチャ諮問委員会（NIAC）による調査が、2005年2月のCVSSバージョン1（CVSSv1）の立ち上げにつながった。その目的は「ソフトウェアの脆弱性に対するオープンで普遍的な標準的深刻度評価を提供するように設計される」ことであった。この初期ドラフトは、ピアレビューや他の組織によるレビューを受けていなかった。2005年4月、NIACは今後の開発においてCVSSの管理者となる組織として、インシデント対応・セキュリティチーム・フォーラム（FIRST）を選定した。

実稼働環境でCVSSv1を使用しているベンダーからのフィードバックにより、「CVSSの初期ドラフトには重大な問題がある」ことが示唆された。2005年4月にCVSSバージョン2（CVSSv2）の策定作業が開始され、最終的な仕様は2007年6月に公開された。

さらなるフィードバックの結果、2012年にCVSSバージョン3の開発作業が始まり、最終的に2015年6月にCVSSv3.0としてリリースされた。

用語

CVSSの評価は、以下の3つの評価基準に分けられる。

1. 脆弱性に内在する性質を評価する基本評価基準（Base metrics）
2. 脆弱性のライフサイクルを通じて変化する特性を評価する現状評価基準（Temporal metrics）
3. 特定の実装や環境に依存する脆弱性を評価する環境評価基準（Environmental metrics）

これらの評価基準グループごとに数値スコアが生成される。ベクターストリング（CVSSv2では単に「ベクター」と呼ばれる）は、すべての評価基準の値をテキストブロックとして表現したものである。

基本評価基準

脆弱性そのものの特性を評価する基準。情報システムに求められる3つのセキュリティ特性、「機密性（ Confidentiality Impact ）」、「完全性( Integrity Impact ）」、「可用性( Availability Impact ）」に対する影響を、ネットワークから攻撃可能かどうかといった基準で評価し、CVSS基本評価値( Base Score )を算出する。CVSSv2の完全なドキュメントはFIRSTから提供されている。以下にその概要を示す。

攻撃元区分

攻撃元区分（Access Vector、AV）は、脆弱性がどのように悪用される可能性があるかを示す。

値	説明	スコア
ローカル (L)	攻撃者は、脆弱なシステムへの物理的アクセス（例：FireWire攻撃）、またはローカルアカウント（例：特権昇格攻撃）を持っている必要がある。	0.395
隣接ネットワーク (A)	攻撃者は、脆弱なシステムのブロードキャストドメインまたはコリジョンドメインにアクセスできる必要がある（例：ARPスプーフィング、Bluetooth攻撃）。	0.646
ネットワーク (N)	脆弱なインターフェースは、OSI参照モデルのレイヤ3以上で動作している。これらのタイプの脆弱性は、しばしばリモートから悪用可能（例：ネットワークサービスでのリモートバッファオーバーフロー）と説明される。	1.0

アクセス元の複雑さ

アクセス元の複雑さ（Access Complexity、AC）の評価基準は、発見された脆弱性を悪用することがどの程度容易または困難であるかを記述する。

値	説明	スコア
高 (H)	狭いウィンドウでの競合状態など、特殊な条件が存在するか、または知識のある人々によって容易に気付かれるようなソーシャル・エンジニアリングの手法を必要とする。	0.35
中 (M)	攻撃の起点に制限がある場合や、脆弱なシステムが一般的ではない非デフォルトの設定で動作している必要があるなど、攻撃にいくつかの追加要件がある。	0.61
低 (L)	システムが多数のユーザーに利用可能である場合や、脆弱な設定が遍在している場合など、脆弱性を悪用するための特別な条件はない。	0.71

攻撃前の認証要否

攻撃前の認証要否（Authentication、Au）の評価基準は、攻撃者が対象を悪用するために認証を行わなければならない回数を記述する。ネットワークにアクセスするための認証などは含まれない。ローカルで悪用可能な脆弱性の場合、この値は初期アクセス後にさらに認証が必要な場合にのみ「単一」または「複数」に設定される。

値	説明	スコア
複数 (M)	脆弱性の悪用には、毎回同じクレデンシャルが使用されたとしても、攻撃者が2回以上認証することが必要である。	0.45
単一 (S)	攻撃者は脆弱性を悪用するために1回認証する必要がある。	0.56
不要 (N)	攻撃者が認証を行う必要はない。	0.704

機密性への影響

機密性への影響（Confidentiality、C）の評価基準は、システムによって処理されるデータの機密性に対する影響を記述する。

値	説明	スコア
なし (N)	システムの機密性に影響はない。	0.0
部分的 (P)	かなりの情報の漏えいがあるが、すべてのデータが利用可能になるわけではないなど、損失の範囲は制限されている。	0.275
全面的 (C)	完全な情報漏えいがあり、システム上の任意の/すべてのデータへのアクセスを提供する。または、一部の制限された情報へのアクセスのみが得られるが、開示された情報が直接的かつ深刻な影響をもたらす。	0.660

完全性への影響

完全性への影響（Integrity、I）の評価基準は、悪用されたシステムの完全性に対する影響を記述する。

値	説明	スコア
なし (N)	システムの完全性に影響はない。	0.0
部分的 (P)	一部のデータまたはシステムファイルの変更が可能であるが、変更の範囲は制限されている。	0.275
全面的 (C)	完全性の完全な喪失。攻撃者は標的システム上の任意のファイルまたは情報を変更できる。	0.660

可用性への影響

可用性への影響（Availability、A）の評価基準は、標的システムの可用性に対する影響を記述する。ネットワーク帯域幅、プロセッササイクル、メモリ、またはその他のリソースを消費する攻撃は、システムの可用性に影響を与える。

値	説明	スコア
なし (N)	システムの可用性に影響はない。	0.0
部分的 (P)	パフォーマンスの低下、または一部の機能の喪失がある。	0.275
全面的 (C)	攻撃されたリソースの可用性の完全な喪失。	0.660

計算方法

これら6つの評価基準は、脆弱性の悪用可能性サブスコアと影響サブスコアを計算するために使用される。これらのサブスコアは、全体的な基本スコアの計算に使用される。

${\textsf {Exploitability}}=20\times {\textsf {AccessVector}}\times {\textsf {AccessComplexity}}\times {\textsf {Authentication}}$

${\textsf {Impact}}=10.41\times (1-(1-{\textsf {ConfImpact}})\times (1-{\textsf {IntegImpact}})\times (1-{\textsf {AvailImpact}}))$

$f({\textsf {Impact}})={\begin{cases}0,&{\text{if }}{\textsf {Impact}}{\text{ = 0}}\\1.176,&{\text{otherwise }}\end{cases}}$

${\textsf {BaseScore}}={\textsf {roundTo1Decimal}}(((0.6\times {\textsf {Impact}})+(0.4\times {\textsf {Exploitability}})-1.5)\times f({\textsf {Impact}}))$

これらの評価基準を連結して、脆弱性のCVSSベクターを生成する。

例

Webサーバーソフトウェアに影響を与えるバッファオーバーフローの脆弱性により、リモートユーザーがシステムをシャットダウンする機能を含め、システムを部分的に制御できるようになる場合を想定する。

評価基準	値	説明
アクセス元	ネットワーク	脆弱性は、標的システムにアクセスできる任意のネットワーク（通常はインターネット全体）からアクセス可能である。
アクセスの複雑さ	低	アクセスのための特別な要件はない。
認証	不要	脆弱性を悪用するための認証は必要ない。
機密性への影響	部分的	攻撃者はシステム上の一部のファイルとデータを読み取ることができる。
完全性への影響	部分的	攻撃者はシステム上の一部のファイルとデータを改ざんできる。
可用性への影響	全面的	攻撃者はシステムをシャットダウンすることで、システムとWebサービスを利用不可 / 応答不能にすることができる。

これにより、悪用可能性サブスコアは10、影響サブスコアは8.5となり、全体的な基本スコアは9.0となる。この場合の基本スコアのベクターは、AV:N/AC:L/Au:N/C:P/I:P/A:Cである。スコアとベクターは通常、受信者が脆弱性の性質を完全に理解し、必要に応じて独自の環境スコアを計算できるように、一緒に提示される。

現状評価基準

CVSSv2での現状評価基準の値は、エクスプロイト（悪用コード）が開発され、公開され、自動化されるにつれて、また緩和策や修正プログラムが利用可能になるにつれて、脆弱性のライフサイクル全体を通じて変化する。

攻撃される可能性

攻撃される可能性（Exploitability、E）の評価基準は、悪用技術または自動化された悪用コードの現在の状態を記述する。

値	説明	スコア
未確認 (U)	悪用コードは利用できないか、悪用は理論的なものである。	0.85
実証コード (P)	概念実証（PoC）の悪用コードまたはデモ攻撃は利用可能であるが、広範な使用には実用的ではない。脆弱性のすべてのインスタンスに対して機能するわけではない。	0.9
機能的コード (F)	機能的な悪用コードが利用可能であり、脆弱性が存在するほとんどの状況で機能する。	0.95
広く普及 (H)	脆弱性は、モバイルコード（ワームやウイルスなど）を含む自動化されたコードによって悪用される可能性がある。	1.0
未評価 (ND)	このスコアを無視するためのシグナルである。	1.0

利用可能な対策のレベル

利用可能な対策のレベル（Remediation Level、RL）は、緩和策や公式の修正プログラムが提供されるにつれて、脆弱性の現状スコアを低下させることを可能にする。

値	説明	スコア
公式の修正プログラム (O)	パッチまたはアップグレードなど、完全なベンダーソリューションが利用可能である。	0.87
一時的な修正プログラム (T)	ベンダーから公式の一時的な修正 / 緩和策が提供されている。	0.90
回避策 (W)	対象製品のユーザーまたは別のサードパーティによって開発または提案された、非公式のベンダー外ソリューションまたは緩和策が利用可能である。	0.95
利用不可 (U)	利用可能な解決策がないか、提案された解決策を適用することが不可能である。これは、脆弱性が特定された時点での修復レベルの通常の初期状態である。	1.0
未評価 (ND)	このスコアを無視するためのシグナルである。	1.0

脆弱性情報の信頼性

脆弱性情報の信頼性（Report Confidence、RC）は、脆弱性の存在に対する信頼度、および脆弱性の技術的詳細の信頼性を測定する。

値	説明	スコア
未確認 (UC)	単一の未確認のソース、または複数の矛盾するソース。噂されている脆弱性。	0.9
未確証 (UR)	大まかに一致する複数のソース。脆弱性についてまだある程度の不確実性が残っている可能性がある。	0.95
確認済 (C)	対象製品のベンダーまたは製造元によって認識および確認されている。	1.0
未評価 (ND)	このスコアを無視するためのシグナルである。	1.0

計算方法

これら3つの評価基準は、すでに計算された基本スコアと組み合わせて使用され、脆弱性の現状スコアとそれに関連するベクターを生成する。

現状スコアを計算するために使用される公式は次のとおりである。

${\textsf {TemporalScore}}={\textsf {roundTo1Decimal}}({\textsf {BaseScore}}\times {\textsf {Exploitability}}\times {\textsf {RemediationLevel}}\times {\textsf {ReportConfidence}})$

例

前述の例を続けると、メーリングリストへの概念実証コードの投稿によってベンダーが脆弱性を最初に知らされた場合、初期の現状スコアは以下の値を使用して計算される。

評価基準	値	説明
攻撃コードの現状	実証コード	基本的な悪用機能を示すための非自動化の概念実証コードが提供されている。
修復レベル	利用不可	ベンダーはまだ緩和策や修正を提供する機会がない。
報告の信頼性	未確認	脆弱性に関する単一の報告がある。

これにより、現状スコアは7.3となり、現状ベクターはE:P/RL:U/RC:UC（完全なベクターはAV:N/AC:L/Au:N/C:P/I:P/A:C/E:P/RL:U/RC:UC）となる。

その後、ベンダーが脆弱性を確認した場合、スコアは8.1に上がり、現状ベクターはE:P/RL:U/RC:Cとなる。

ベンダーからの一時的な修正が提供されるとスコアは7.3（E:P/RL:T/RC:C）に戻り、公式の修正が提供されるとさらに7.0（E:P/RL:O/RC:C）まで下がる。影響を受けるすべてのシステムが修正またはパッチ適用されたことを確信することは不可能であるため、ベンダーの対応に基づいて現状スコアを特定のレベルより低くすることはできず、脆弱性に対する自動化されたエクスプロイトが開発された場合はスコアが上がる可能性がある。

環境評価基準

CVSSv2での環境評価基準は、基本スコアと現在の現状スコアを使用して、脆弱性のある製品やソフトウェアが導入されている環境の状況に合わせて脆弱性の深刻度を評価する。この基準は通常、影響を受ける組織によって主観的に計算される。

二次的被害の可能性

二次的被害の可能性（Collateral Damage Potential、CDP）の評価基準は、脆弱性が悪用された場合の、機器（および人命）などの物理的資産に対する潜在的な損失や影響、または影響を受ける組織に対する財政的影響を測定する。

値	説明	スコア
なし (N)	財産、収益、生産性の損失の可能性がない	0
低 (L)	資産への軽微な損害、または収益や生産性の軽微な損失	0.1
中低 (LM)	中程度の損害または損失	0.3
中高 (MH)	深刻な損害または損失	0.4
高 (H)	壊滅的な損害または損失	0.5
未評価 (ND)	このスコアを無視するためのシグナルである。	0

影響を受ける対象システムの範囲

影響を受ける対象システムの範囲（Target Distribution、TD）の評価基準は、環境内にある脆弱なシステムの割合を測定する。

値	説明	スコア
なし (N)	標的となるシステムが存在しないか、実験室環境にのみ存在する	0
低 (L)	システムの1〜25%がリスクにさらされている	0.25
中 (M)	システムの26〜75%がリスクにさらされている	0.75
高 (H)	システムの76〜100%がリスクにさらされている	1.0
未評価 (ND)	このスコアを無視するためのシグナルである。	1.0

対象システムのセキュリティ要求度

対象システムが要求されるセキュリティ特性に関して、機密性要件（CR）、完全性要件（IR）、可用性要件（AR）の3つの追加の評価基準は、ユーザーの環境に応じて環境スコアを微調整できるようにする。

値	説明	スコア
低 (L)	（機密性 / 完全性 / 可用性）の喪失が組織に限定的な影響しか与えない可能性が高い。	0.5
中 (M)	（機密性 / 完全性 / 可用性）の喪失が組織に深刻な影響を与える可能性が高い。	1.0
高 (H)	（機密性 / 完全性 / 可用性）の喪失が組織に壊滅的な影響を与える可能性が高い。	1.51
未評価 (ND)	このスコアを無視するためのシグナルである。	1.0

計算方法

5つの環境評価基準は、以前に評価された基本および現状の評価基準と組み合わせて使用され、環境スコアを計算し、関連する環境ベクターを生成する。

${\textsf {AdjustedImpact}}=\min(10,10.41\times (1-(1-{\textsf {ConfImpact}}\times {\textsf {ConfReq}})\times (1-{\textsf {IntegImpact}}\times {\textsf {IntegReq}})\times (1-{\textsf {AvailImpact}}\times {\textsf {AvailReq}})))$

${\textsf {AdjustedTemporal}}={\textsf {TemporalScore}}{\text{ recomputed with the }}{\textsf {BaseScore}}{\text{s }}{\textsf {Impact}}{\text{ sub-equation replaced with the }}{\textsf {AdjustedImpact}}{\text{ equation}}$

${\textsf {EnvironmentalScore}}={\textsf {roundTo1Decimal}}(({\textsf {AdjustedTemporal}}+(10-{\textsf {AdjustedTemporal}})\times {\textsf {CollateralDamagePotential}})\times {\textsf {TargetDistribution}})$

例

前述の脆弱なWebサーバーが、銀行によってオンラインバンキングサービスを提供するために使用されており、ベンダーから一時的な修正プログラムが提供されている場合、環境スコアは次のように評価される。

評価基準	値	説明
二次的被害の可能性	中高	この値は、脆弱なシステムが悪用された場合に攻撃者がどのような情報にアクセスできるかによって異なる。この場合、一部の個人銀行情報が利用可能であると想定しているため、銀行に対する深刻な評判への影響がある。
ターゲット分布	高	銀行のすべてのWebサーバーで脆弱なソフトウェアが実行されている。
機密性要件	高	顧客は自らの銀行情報が機密であることを期待している。
完全性要件	高	財務情報および個人情報は、許可なく変更可能であってはならない。
可用性要件	低	オンラインバンキングサービスの利用不可は、顧客にとって不便になる可能性が高いが、壊滅的ではない。

これにより、環境スコアは8.2となり、環境ベクターはCDP:MH/TD:H/CR:H/IR:H/AR:Lとなる。このスコアは7.0〜10.0の範囲内にあるため、影響を受ける銀行のビジネスという状況においては「緊急（Critical）」な脆弱性に該当する。

バージョン2に対する批判

いくつかのベンダーや組織はCVSSv2に対する不満を表明した。

Open Source Vulnerability Databaseを管理するRisk Based SecurityとOpen Security Foundationは共同で、CVSSv2の欠点と失敗に関する公開書簡をFIRSTに発表した。著者らは複数の評価基準における粒度の欠如を指摘し、その結果生じるCVSSベクターとスコアが、タイプやリスクプロファイルの異なる脆弱性を適切に区別できていないとした。また、CVSSスコアリングシステムは、脆弱性の正確な影響についての知識を求めすぎているとも指摘された。

Oracleは、公式のCVSS仕様における「部分的」と「全面的」の間の説明のギャップを埋めるために、機密性、完全性、可用性の新たな評価基準値である「Partial+」を導入した。

バージョン3

これらの批判のいくつかに対処するため、2012年にCVSSバージョン3の開発が開始された。最終仕様はCVSSv3.0と名付けられ、2015年6月にリリースされた。仕様書に加え、ユーザーガイドとサンプル文書も公開された。

いくつかの評価基準が変更、追加、および削除された。0から10の既存のスコアリング範囲を維持しながら、新しい評価基準を組み込むために数値計算式が更新された。CVSSv2に対してNVDが定義した（標準の一部ではなかった）カテゴリと同様に、「なし (0)」「低 (0.1-3.9)」「中 (4.0-6.9)」「高 (7.0-8.9)」「緊急 (9.0-10.0)」というテキストによる深刻度評価が定義された。

バージョン2からの変更点

基本評価基準

基本ベクターには、ユーザーの関与（UI）および必要な特権レベル（PR）という新しい評価基準が追加され、悪用にユーザーの操作が必要な脆弱性や、ユーザーまたは管理者の特権が必要な脆弱性を区別するのに役立つようになった。以前は、これらの概念はCVSSv2のアクセス元区分評価基準の一部であった。UIは「不要」または「要」の値を取ることができ、ユーザーとしてログインする必要がない攻撃はより深刻であるとみなされる。PRは「不要」「低」または「高」の値を取ることができ、同様に、必要な権限が少ない攻撃ほど深刻である。

基本ベクターには、新しくスコープ（S）という評価基準も導入された。これは、脆弱性が悪用された後にシステムやネットワークの他の部分への攻撃に使用される可能性があるかどうかを明確にするために設計されている。これらの新しい評価基準により、基本ベクターは評価対象の脆弱性の種類をより明確に表現できるようになった。

機密性、完全性、可用性（C、I、A）の評価基準は、CVSSv2の「なし」「部分的」「全面的」ではなく、「なし」「低」「高」のスコアを持つように更新された。これにより、CIA基準に対する脆弱性の影響を判断する際の柔軟性が向上する。

アクセス元の複雑さ（Access Complexity）は、攻撃条件の複雑さ（Attack Complexity、AC）に変更され、アクセス権限が別の評価基準に移動したことが明確になった。この評価基準は、現在ではこの脆弱性の悪用の再現性がどの程度であるかを記述している。攻撃者が完璧なタイミングやその他の状況（別の評価基準であるユーザーの操作を除く）を必要とし、その後の試行で容易に再現できない場合、ACは「高」となる。

攻撃元区分（AV）には、実行するためにデバイスまたはシステムへの物理的アクセスが必要な脆弱性を記述するための、物理（P）という新しい評価基準値が含まれた。

現状評価基準

現状評価基準は、本質的にCVSSv2から変更されていない。

環境評価基準

CVSSv2の環境評価基準は完全に削除され、本質的に修正されたベクターとして知られる2つ目の基本スコアに置き換えられた。修正された基本スコアは、世界全体と比較した組織または企業内の差異を反映することを目的としている。特定の環境に対する機密性、完全性、可用性の重要性を捉えるための新しい評価基準が追加された。

バージョン3に対する批判

2015年9月のブログ記事で、CERT Coordination Centerは、モノのインターネット（IoT）などの新興技術システムにおける脆弱性のスコアリングに使用する場合のCVSSv2およびCVSSv3.0の限界について論じた。

バージョン3.1

2019年6月17日に、CVSSのマイナーアップデートがリリースされた。CVSSv3.1の目標は、新しい評価基準や評価基準値を導入することなく、既存のCVSSv3.0規格を明確にして改善することであり、スコアの提供者と利用者の双方が新しい標準を摩擦なく採用できるようにすることであった。使いやすさは、CVSS標準を改善する際の主要な考慮事項であった。CVSSv3.1で行われたいくつかの変更は、CVSSv3.0で導入された概念の明確性を向上させ、それによって標準全体の使いやすさを向上させるためのものである。

FIRSTは、業界の専門家の意見を取り入れて、過去15年以上にわたって開発されてきた脆弱性、製品、プラットフォームにさらに適用できるよう、CVSSの強化と改良を続けてきた。CVSSの主な目的は、多くの異なる構成要素間で脆弱性の深刻度をスコアリングするための確定的かつ反復可能な方法を提供し、CVSSの消費者がこのスコアを、自らの特定の環境とリスク許容度に固有のリスク、修復、および緩和の大規模な意思決定マトリクスへの入力として使用できるようにすることである。

CVSSv3.1仕様への更新には、アクセス元区分、必要な特権レベル、スコープ、セキュリティ要件などの既存の基本評価基準の定義の明確化と説明が含まれている。また、CVSS Extensions Frameworkと呼ばれる、CVSSを拡張する新しい標準的な方法も定義され、スコア提供者が公式の基本、現状、および環境評価基準を維持しながら、追加の評価基準と評価基準グループを含めることができるようになった。この追加の評価基準により、プライバシー、安全、自動車、ヘルスケアなどの業界セクターは、コアのCVSS標準外の要因をスコアリングできる。最後に、CVSS用語集が拡張および改良され、CVSSv3.1のドキュメント全体で使用されるすべての用語が網羅された。

バージョン4.0

バージョン4.0は2023年11月に正式にリリースされ、FIRST.orgで利用可能である。いくつかの明確化の中で最も注目すべき変更は、脆弱性を悪用するために標的側でどのような条件が必要であるかを評価する新しい基本評価基準である「攻撃条件（Attack Requirements）」が、「攻撃の条件の複雑さ（Attack Complexity）」の評価基準を補完することである。さらに、「影響（Impact）」の評価基準は、脆弱なシステム自身への影響と、後続システムへの影響に分割された（これは以前のバージョンの「スコープ（Scope）」評価基準に代わるものである）。

基本評価基準は現在次のようになっている。

• 攻撃元区分 (AV): 脆弱性を悪用できる（物理的な）経路はどれか。[N] ネットワーク、[A] 隣接（すなわち、直接の接続に限定される）、[I] ローカル（例: SSHやキーボード経由）、または [P] 物理（例: ハードウェアの操作や観察）。
• 攻撃の条件の複雑さ (AC): 攻撃者が回避しなければならない対策が他にもあるか、またそれを実行するのはどれくらい困難か。[L] 低、または [H] 高（例: データ実行防止機能）。
• 攻撃条件 (AT): 攻撃者が影響を及ぼすことができない、攻撃に必要な条件はあるか。[N] 不要、または [P] 要（例: 競合状態に勝つ必要がある、またはシステムが特定の状態にある）。
• 必要な特権レベル (PR): 標的システム上で何らかの権限が必要か。[N] 不要（未認証）、[L] 低（一般ユーザー）、または [H] 高（管理者アクセス）。
• ユーザーの関与 (UI): 攻撃を可能にするために、システムの（正当な）ユーザーが何かをする必要があるか。[N] 不要、[P] 受動的（例: 悪意のあるWebサイトを誤って訪問する）、または [A] 能動的（例: 悪意のあるOfficeマクロを実行する）。
• 脆弱なシステムの機密性への影響 (VC): [N] なし、[L] 低、または [H] 高。
• 脆弱なシステムの完全性への影響 (VI): [N] なし、[L] 低、または [H] 高。
• 脆弱なシステムの可用性への影響 (VA): [N] なし、[L] 低、または [H] 高。
• 後続システムの機密性への影響 (SC): [N] なし、[L] 低、または [H] 高。
• 後続システムの完全性への影響 (SI): [N] なし、[L] 低、または [H] 高。
• 後続システムの可用性への影響 (SA): [N] なし、[L] 低、または [H] 高。

これらの基本評価基準に加えて、エクスプロイトの公開状況、環境固有の脅威モデリング、システム復旧などに関するオプションの評価基準が存在する。

2026年1月、標準化団体は新しいコンシューマー向け実装ガイドをリリースし、展開環境と脅威活動をより正確に反映するスコアを生成するための脅威および環境評価基準の使用法を詳述した。このガイドでは、これらの追加の評価基準グループが現実世界でのトリアージとリソース割り当てを改善するためのスコアをどのように向上させるかを説明する成熟度モデルも導入されている。

例

説明のために、オンラインショップにSQLインジェクションの脆弱性があるとする。オンラインショップソフトウェアのデータベースユーザーは、データベースへの読み取りアクセスのみを持っている。さらに、インジェクションは登録済みの顧客にのみ表示されるショップのビューに存在している。CVSS 4.0の基本ベクターは以下のようになる。

• AV:N Web経由で脆弱性を引き起こすことができるため。
• AC:L SQLインジェクションはスクリプト経由で確実に悪用できるため（オンラインショップに対策がないと仮定）。
• AT:N 攻撃は特定のシステム条件に依存しないため。
• PR:L 攻撃者は一般ユーザーとして認証される必要があるが、管理者権限は不要なため。
• UI:N 他のユーザーが関与しないため。
• VC:H 攻撃者はデータベース内のすべてのテーブルを読み取ることができるため。
• VI:N 攻撃者に書き込みアクセス権がないため。
• VA:L 攻撃者がデータベース上で時間のかかるクエリを実行し、一時的にデータベースを遅くしたり応答しなくさせたりする可能性があるため。
• SC:N （後続のシステムに関する詳細情報がないため）
• SI:N （後続のシステムに関する詳細情報がないため）
• SA:L 注文管理とロジスティクスに関与する他のシステムが、応答しないデータベースの影響を受けることが予想されるため。

これにより、ベクターはAV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:L/SC:N/SI:N/SA:Lとなる。

導入

各バージョンのCVSSは、脆弱性の深刻度を定量化するための主要な方法として、次のような幅広い組織や企業に採用されている。

• National Vulnerability Database（NVD）
• Open Source Vulnerability Database（OSVDB）
• CERT Coordination Center（特にCVSSv2の基本、現状、環境評価基準を活用している）

関連項目

• 共通脆弱性タイプ一覧（CWE）
• 共通脆弱性識別子（CVE）
• 共通攻撃パターン一覧（CAPEC）

外部リンク

• The Forum of Incident Response and Security Teams (FIRST) CVSS site
• National Vulnerability Database (NVD) CVSS site
• Common Vulnerability Scoring System v2 Calculator