CVSS v4.0とは？脆弱性管理の「共通のものさし」を正しく理解するための基礎知識

そもそもCVSSとは？

共通脆弱性評価システム（CVSS）は、ソフトウェア、ハードウェア、またはファームウェアの脆弱性が持つ技術的な特性を捉え、その深刻度を伝えるためのオープンなフレームワークです。

米国を拠点とする非営利団体FIRST.Org, Inc. (FIRST) ^*1)によって所有・管理されており、ベンダーやプラットフォームに依存しない標準化されたスコアリング手法を提供しています

4つの評価基準（メトリクスグループ）

CVSSは、単一の完成されたスコアを提供するものではなく、以下の4つのメトリクスグループを通じて、段階的に深刻度を捉えていきます。

1. 基本メトリクスグループ（Base Metrics Group）
   時間や環境が変わっても変化しない、脆弱性そのものに内在する性質を評価します（例：攻撃の複雑さ、機密性への影響など）。一般的にニュースなどで目にするスコアはこれを指すことが多いです。これは、攻撃者が脆弱性を完全に理解していると仮定した「最悪の事態」を想定した評価であり、いわば脆弱性のカタログスペックです 。
2. 脅威メトリクスグループ（Threat Metrics Group）
   時間とともに変化する要素を評価します（例：その脆弱性を悪用する攻撃コードが世に出回っているかなど）。
3. 環境メトリクスグループ（Environmental Metrics Group）
   ユーザーの特定の利用環境に依存する要素を評価します（例：そのシステムが組織にとってどれほど重要か、緩和策はあるかなど）。
4. 補足メトリクスグループ（Supplemental Metrics Group）
   スコア（数値）そのものには影響しませんが、対応の優先順位を決めるための追加情報を提供します（例：人命に関わる「安全性（Safety）」への影響や、攻撃の「自動化（Automatable）」が可能かなど）。

【補足】そのスコアは何を評価しているのか？（命名法）

CVSS命名法	使用されるCVSSメトリクス
CVSS-B （Base）	基本指標。ベンダーが公表する、脆弱性そのものに対する評価。
CVSS-BT (Base + Threat)	基本指標に脅威を追加した指標。
CVSS-BE (Base + Environmental)	基本指標に環境の指標となる自社のシステム構成、重要度、緩和策等を加味した指標。
CVSS-BTE（Base + Threat + Environmental）	基本指標に環境の指標と脅威の指標を加味した指標。

私たちがニュースやツールで目にする数字の多くは、まだ自社の環境が入っていない CVSS-B です。脆弱性の最新トレンドや自社の利用環境を反映した CVSS-BTE を算出することで、初めてその脆弱性が自社にとってどれほど危険かという「現実的な数字」が見えてきます 。

CVSS v4.0の仕様書では、基本スコア（CVSS-B）を「組織固有のリスク評価」に向けた重要かつ不可欠な入力情報として位置づけています。ただし、その情報をさらに有用なものにするためには、ユーザー側でしか把握できない「脅威」や「環境」の情報を組み合わせ、スコアを強化することが推奨されています。ベンダーから提供される共通情報に、自社ならではの文脈を付け加えることで、より実態に即した包括的なリスク判断が可能になる、という考え方です。

スコアと深刻度のレベル

評価結果は 0.0 から 10.0 の数値で表され、数値が高いほど深刻度が高くなります。スコアに応じて、以下のような深刻度のレベル（Rating）が定義されています。

• None (なし): 0.0
• Low (低): 0.1 - 3.9
• Medium (中): 4.0 - 6.9
• High (高): 7.0 - 8.9
• Critical (緊急): 9.0 - 10.0

基本スコアだけでは、実際の環境におけるリスクを正確に反映できない場合があります。そのため、CVSSの仕様書では、基本スコア（Base Score）だけでなく、自分の組織の環境に合わせて「脅威」や「環境」メトリクスを加味して評価することが強く推奨されています。

膨大なパターンをシンプルに整理する仕組み

CVSS v4.0は、脆弱性の状況を非常にきめ細かく表現できるフレームワークです。CVSS v4.0がこれほどまでに精密なのは、評価項目（メトリクス）ごとに詳細な選択肢が用意されているからです。各メトリクスの選択肢の数を掛け合わせると、理論上のパターンは15,355,584通り（約1,500万通り）にも及びます。

1. 基本メトリクス（脆弱性そのものの性質：11項目）

攻撃のしやすさや、被害の大きさを決めるベースの項目です。

AV(4), AC(2), AT(2), PR(3), UI(3), VC(3), VI(3), VA(3), SC(3), SI(3), SA(3)

2. 脅威メトリクス（脆弱性が攻撃される可能性：1項目）

攻撃コードが世に出回っているかなどの状況を加味します。

E(3)

3. 環境メトリクス（組織ごとの事情：14項目）

「その資産がどれほど重要か」という優先度（CR/IR/AR）に加え、基本メトリクスの11項目すべてを「自分の環境に合わせて上書き」できる項目が用意されています。

CR(4), IR(4), AR(4) ＋ MAV(5), MAC(3), MAT(3), MPR(4), MUI(4), MVC(4), MVI(4), MVA(4), MSC(4), MSI(4), MSA(4)

※ 頭に M（Modified：修正）がついているのは、「基本項目（Base）を、自分たちの対策状況に合わせて変更する」という意味です。

なぜ「上書き」が必要なのか？

例えば、基本評価（Base）では「ネットワークから攻撃可能（AV:N）」な脆弱性でも、自分の環境では「強力なファイアウォールで遮断している」という場合、環境メトリクスの MAV（修正攻撃経路） を「物理(P)」などに上書きすることで、実態に即した正しいスコアを出すことができるのです。

まとめ

個々の項目の単純な組み合わせは膨大になりますが、CVSS v4.0の計算アルゴリズムによって、評価において意味のあるパターン（全評価空間）は 15,355,584通り に集約・定義されています。

【ここがポイント！】1,500万通りをどう扱うのか？

「1,500万通りもあっては評価しきれない」と感じるかもしれませんが、CVSS v4.0の計算アルゴリズムでは、この膨大な組み合わせを、専門家が「深刻度が同等である」と定義した 270通りの深刻度パターン に凝縮して管理しています 。

この「膨大なデータを意味のある数まで凝縮し、専門家の知見でランク付けする」という仕組みこそが、v4.0が「より人間の直感に近い」と言われる理由です 。具体的なスコア算出のステップについては、『CVSS v4.0のスコアはどのように決まるのか？』で詳しく解説します。

※ 各略称（AV、ACなど）の具体的な定義については、公式のCVSS v4.0 仕様書 ^*2)に詳しく記載されています。ここでは『これだけ多くの視点で脆弱性を捉えているんだな』という精密さを感じていただければ十分です

*1) FIRST.Org　https://www.first.org/
*2) 公式のCVSS v4.0仕様書　https://www.first.org/cvss/v4.0/specification-document

CVSS v3.1とv4.0は何が違うの？

評価の「精度」と「納得感」の向上

CVSS v4.0 へのアップデートは、単なる項目の追加ではなく、「脆弱性の深刻度をどう定義するか」という計算思想そのものが変わりました。

これまでの v3.x では、あらかじめ決められた数式に値を代入する「算術的アプローチ」を採用していました。 しかし、この方式では特定の項目を一つ変えただけでスコアが極端に上下する不自然さや、専門家の直感と乖離するスコアが算出される課題がありました。 v4.0 では、専門家が合意した基準値（ルックアップテーブル）と多次元的な補間計算を組み合わせることで、より人間の直感に近い、スムーズで納得感のあるスコア変動を実現しています。

主な変更ポイント

• 「攻撃前提条件 (AT: Attack Requirements)」の新設
  v3.1 では「攻撃の複雑さ (AC)」にまとめられていたものが分離されました 。例えば「特定の OS 設定が必要」といった条件を個別に評価できるため、「自社ではその条件が揃わないから安全だ」という論理的な判断（引き算）がしやすくなりました 。
• 「環境」による上書き機能の強化
  基本評価（Base）を、自社の環境（Environmental）に合わせて「上書き（Modified）」する項目が整理されました 。これにより、ベンダーが提示したカタログスペックのスコアを、自社の対策状況（ファイアウォールの有無など）を反映した「実効リスク」へとより正確に調整できます 。
• 「補足メトリクス」による多角的な視点
  スコア（数値）には影響しませんが、人命への影響（Safety）や攻撃の自動化（Automatable）の可否など、対応の優先順位を決めるための重要なヒントが提供されるようになりました 。

【参考】計算手法の進化：数式から「多次元マップ」へ

以前の CVSS v3.1 までは、以下のような固定の数式に各値を代入してスコアを算出していました。

１．基本スコアの構成：　$BaseScore = Roundup(Minimum[(Impact + Exploitability), 10])$

２．攻撃容易性 ($Exploitability$) : 　$Exploitability = 8.22 \times AV \times AC \times PR \times UI$

※ここで $AV$（攻撃元区分）や $AC$（複雑さ）などは、それぞれ 0.85 や 0.62 といった特定の係数に置き換えて計算されます。

３．影響度 ($Impact$):　$Impact = 6.42 \times ISS$

$ISS = 1 - [(1 - ConfImpact) \times (1 - IntegImpact) \times (1 - AvailImpact)]$

v3.1 までのアプローチと課題

• 一律の計算
  「攻撃の複雑さ」や「権限」などの項目を一律の重みで掛け合わせる数式だったため、特定の組み合わせにおいて「現場の感覚」とスコアが微妙にズレるケースがありました 。
• 不自然な変動
  項目を一つ変えただけでスコアが急激に跳ね上がったり、逆にほとんど変わらなかったりする「不連続性」が課題として挙げられていました 。

v4.0 での進化
v4.0 ではこの固定数式による一律計算を卒業しました 。 代わりに、専門家が「このケースなら何点」と合意した270通りの深刻度パターンをベースに、入力値との距離を測って微調整する方式を採用しています 。

これにより、「少し条件が緩和されれば、少しだけスコアが下がる」といった、より直感的で納得感のあるスコア算出が可能になったのです 。

CVSS v4.0を形づくる「6つの評価軸（EQ）」

最初のセクションで説明したの1500万通りを超える評価パターンを最終的なスコア（0.0～10.0）へ一貫性をもって変換するために、CVSS v4.0では、6 つのグループ (EQ: Equivalence Groups) を採用しています。これは性質の近いメトリクスを6つのグループ（EQ1～EQ6）に整理統合することで複雑な組み合わせを数学的に管理可能なレベルへと集約しています。EQは大きく3つのグループ、攻撃容易性、影響度、調整用とに分けることができます。

攻撃容易性（Exploitability）～ 攻撃が成立するための「障壁」

脆弱性がある対象（脆弱なシステム）に対し、攻撃がどれだけ技術的に容易かを評価します。評価にあたっては「攻撃者は脆弱性について完璧な知識を持っている」と仮定します。攻撃者が脆弱性を悪用するために、どれだけのハードルを越える必要があるかを評価します。v4.0では、これらが組み合わさってEQ1とEQ2という指標になります。

• EQ1：攻撃レベル（AV / PR / UI の組み合わせ）
  • 攻撃元区分 (AV)：攻撃者がどこからアクセス可能か。
  • 必要な権限 (PR)：攻撃実行前に、認証が必要か。
  • ユーザー関与 (UI)：ユーザーに特定の操作をさせる必要があるか。
• EQ2：複雑さと条件（AC / AT の組み合わせ）
  • 攻撃条件の複雑さ (AC)：回避不能なセキュリティ制御を突破する必要があるか。
  • 攻撃前提条件 (AT)：【v4.0新設】 ターゲットが特定の構成になっている必要があるか。

影響度（Impact）〜 セキュリティ侵害の波及範囲と大きさ

v4.0では、被害が及ぶ場所を「脆弱なシステム」と「後続システム」に分け、それぞれ個別に評価します。

• EQ3：脆弱なシステムへの影響（VC / VI / VA の組み合わせ） 脆弱性が存在するシステムそのものへの直接的な被害。
  • 脆弱性が存在するシステムそのものへの「機密性・完全性・可用性」の被害を評価します。
• EQ4：後続システムへの影響（SC / SI / SA の組み合わせ） 脆弱なシステムを「踏み台」にして外部に及ぶ被害。
  • 脆弱なシステムを「踏み台」にして、外部（他のマシンやデータ、人命の安全など）に及ぶ被害を評価します。

脅威指標（Threat）と環境指標（Environmental）

基本スコアを決めるEQ1〜4に加えて、CVSS v4.0では以下の要素も統合して計算できます。

• EQ5：脅威（Exploit Maturity）：攻撃コードがどれくらい出回っているか。
• EQ6：影響の調整（環境要件）：自社の環境において、そのデータの機密性がどれほど重要か（CR/IR/AR）。

これら6つのEQがすべて組み合わさって、最終的なスコアが決定されます。

ベンダーが公表する「CVSSスコア」の具体例

脆弱性が公表されるとき、ベンダーは修正プログラム（パッチ）とともに、その脆弱性の「カタログスペック」であるCVSSスコアを提示します。

例：Google Cloudにおける「Protobuf-Python」の脆弱性

• 掲載元: Google Cloud Security Bulletins^*3)
• 掲載箇所: Bulletin ID: GCP-2025-043
• 脆弱性名: CVE-2025-4565^*4) (Unbounded recursion in Python Protobuf)
• 公式評価:
  • Severity: High
  • CVSS v4.0 Score: 8.2
  • Vector String: CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

「Protobuf」と「Protobuf-Python」とは
「Protobuf」はGoogleが開発した構造化データのシリアライズを目的としたスキーマ。構造化データをバイト列に変換する仕組みです。
「Protobuf-Python」はProtobufをPythonでつかえるようにしたもの。

この脆弱性はデータの「再帰処理（入れ子構造）」に脆弱性があり、正常なデータの場合は「箱の中に、小さな箱が入っています」。その場合、プログラムは中身を順番に開けて処理し、終わりますが、悪意のあるデータをこの構造に入れることで 攻撃者は、「無限に続く合わせ鏡」のような構造をしたデータを送れるようになります。その結果、プログラムは「箱の中に箱、その中にまた箱……」と律儀に中身を確認し続け、いつまで経っても終わらない「無限ループ」に陥ります。プログラムがこの「無限ループ」に全エネルギー（CPUのリソース）を注ぎ込んでしまうため、サービスの停止やリソースの枯渇を引き起こします。

【 ここが重要！ 】
このCVSSスコアは「標準的な最悪ケース」 この点数は、ベンダーが「標準的な構成ならこうなる」と想定したものです。それでは次にVector Stringを具体的に見ていきます。

1. 攻撃のしやすさ（Exploitability）

攻撃者が「どうやって」「どのくらい簡単に」攻撃できるかを示します。

• AV:N (Attack Vector: Network)
  • 攻撃ベクトル：ネットワーク － インターネット越しに遠隔地から攻撃可能です。
• AC:L (Attack Complexity: Low)
  • 攻撃の複雑さ：低い － 特別な技術や、何度も失敗を繰り返すような難しい仕掛けは不要です。
• AT:P (Attack Requirements: Present)
  • 攻撃前提条件：あり － ここが重要！「複雑さ（AC）」とは別に、ターゲットが特定の構成になっている必要があるなど、「攻撃が成立するための前提条件」を個別に評価できるようになりました。
• PR:N (Privileges Required: None)
  • 必要な権限：なし － ログインIDやパスワードを持たない外部の人間でも攻撃可能です。
• UI:N (User Interaction: None)
  • ユーザー関与：なし － 被害者が「リンクをクリックする」などの操作をしなくても、勝手に攻撃が成立します。

これらよりインターネット越しに（AV:N）、特別な条件が揃えば（AT:P）、誰でも実行できる脆弱性であることが分かります。

2. 脆弱なシステムへの影響（Vulnerable System Impact）

攻撃を受けた「そのシステム自体」がどうなるかを示します。

• VC:N (Vulnerable Confidentiality: None)
  • 機密性への影響：なし － データが盗まれることはありません。
• VI:N (Vulnerable Integrity: None)
  • 完全性への影響：なし － データが改ざんされることはありません。
• VA:H (Vulnerable Availability: High)
  • 可用性への影響：高 － システムがクラッシュしたり、サービスが完全に停止したりします。

これらより、この脆弱性は、無限ループなどを起こしてサービスを止める「DoS攻撃」に近い性質であることがわかります。

３. Vector Stringを自社環境に当てはめ考えてみよう

CVE-2025-4565は『インターネットから誰でも（1の要素）、サービスを止めることができる（2の要素）』という、非常に厄介な性質を持っていることが分かります。

ここで注意すべきことはCVSSスコアは「あなたの環境」で変化するということです。

このベンダーが算出した「8.2」というスコアを、自社環境に即して、脆弱性が及ぼす影響の度合いを反映させます。

*3)　https://docs.cloud.google.com/support/bulletins#gcp-2025-043　
*4)　https://www.cve.org/CVERecord?id=CVE-2025-4565

CVSS v4.0のスコアはどのように決まるのか？

CVSS v4.0における基本スコア（Base Score）の計算方法は、以前のバージョン（v3.x）から大きく変更されました。これまでの「数式に値を代入して計算する」方式から、あらかじめ定義された「270通りの深刻度パターン」とルックアップテーブルを用いてスコアを導き出すが採用されています。

この方式では、専門家による深刻度評価ランキングとして整理し、それを数値スコアに変換することで、より実務的な感覚に近い評価を実現しています。

スコア算出のプロセス

なぜv4.0のスコアは、これまでの数式よりも「現場の感覚」に近いのか。その背景には、以下のプロセスがあります。

自社に最適化された「特定の1パターン」の特定

実際に自社の状況に当てはめる手順を見てみましょう。

脆弱性の特性を評価するための各項目（メトリクス）の値を決定します。ベンダーの情報をベースに、自社の環境や最新の脅威状況を反映させ、スコアを自社向けに最適化します。FIRST公式サイトのCVSS v4.0計算ツール^*7)を使用することで計算が簡単に行えます。

入力する際のポイントは次の3つです。

1. ベンダーから受け取る情報（Base）
   攻撃の通り道（AV）や、システムへの影響（VA）など、脆弱性の「不変の性質」であり、いわば「カタログスペック」です。 ここでの評価は、「攻撃者がその脆弱性について完璧な知識を持っている」と仮定^*8)して行われます。「見つけるのが難しいから安全」といった、攻撃者のスキルに依存する甘い見積もりを排除し、最悪の事態を想定した数値になっています。
2. 自社で追加する情報（Threat / Environmental）
   「今、攻撃が流行っているか（E）」や「このシステムは止まっていいのか（AR）」といった、ベンダーには知り得ない「変動する状況」です。
3. 最悪値の選択（迷った時のルール）
   常に「最悪のケース」を想定する。自社の状況（環境メトリクス）を判断する際、「このシステム、重要度は中くらいかな？それとも高いかな？」と迷うことがあるかもしれません。そんな時は、「よりスコアが高くなる（危険な）方」を選択することが推奨されています。「たぶん大丈夫だろう」と低めに見積もって、万が一の際に対応が遅れるリスクを避けるためです。「不確かな状況であれば、まずは最悪の事態に備えておく」というセキュリティ運用の鉄則を反映した設計と言えるでしょう。

*7)　FIRST公式サイトのCVSS v4.0計算ツール「Common Vulnerability Scoring System Version 4.0 Calculator」　https://www.first.org/cvss/calculator/4.0
*8)　CVSS v4.0の仕様書（Section 1.2）には、「すべてのメトリクスは、攻撃者が脆弱性について完璧な知識を持っているという仮定の下で評価されるべきである」と明記されています。もし「攻撃者が仕組みに気づかないかもしれない」という希望的観測を評価に入れてしまうと、評価結果が人によってバラバラになり、「共通のものさし」として機能しなくなります。 「見つけにくさ」を無視して「技術的な脆弱さ」だけを数値化する。これが、世界中で信頼されるスコアを生むための鉄則なのです。

CVSS v4.0を「戦略的運用」につなげるために

CVSS v4.0は、脆弱性の深刻度をより実態に即して正確に評価できる優れた指標です。 しかし、実際の運用において成功を収めるには、「精度」と「スピード」の両立が不可欠です。

毎日発生する膨大な脆弱性に対し、攻撃コードの流布状況（E：脅威メトリクス）の変化をすべて手動で追い続け、再計算を行うのは、現実的な運用としては非常に大きな負担となります。CVSS v4.0は脆弱性の本質を測る優れた指標ですが、その精度を維持するには、時間の経過とともに変化する「脅威インテリジェンス」を常に反映し続けなければならないという、高度な運用コストが伴います。

この「情報の鮮度管理」を自動化し、戦略的なリスク管理を実現するのが、Tenable社のVPR（Vulnerability Priority Rating）という選択肢です。

• CVSS v4.0：脆弱性が持つ潜在的なポテンシャル（深刻度）を正しく理解し、評価の根拠とする。
• VPR：日々刻々と変わる膨大な脅威情報から「今、本当に対処すべき3%」をリアルタイムに自動判別する。

このように、「不変の物差し（CVSS）」と「動的なエンジン（VPR）」を組み合わせることで、初めて脆弱性管理は「形だけの作業」から「攻めのセキュリティ」へと進化します。

※VPRを活用した「脆弱性管理の自動化」の詳細については、次回のブログで詳しくご紹介する予定です。