CVSS (共通脆弱性評価システム)

1. 概要

定義: CVSS(Common Vulnerability Scoring System)とは、国際的なインシデント対応フォーラムである FIRST(Forum of Incident Response and Security Teams)が管理する公開かつ標準化された脆弱性深刻度評価フレームワークであり、ソフトウェア脆弱性の技術的特性を定められたメトリクスで測定し、0.0~10.0 の定量スコアと等級(None・Low・Medium・High・Critical)へ換算することで、異なる組織・製品・国が同一の尺度で脆弱性の相対的リスクを比較・共有できるようにする開放型の枠組みである。

CVSS が登場した背景は、脆弱性情報の共通言語の不在にある。 2000年代初頭に脆弱性公開が急増すると、各ベンダーが「緊急」「重要」「中程度」といった独自の等級をそれぞれ付与し、同一の欠陥であっても供給者ごとに深刻度の判断が異なったため、需要者(セキュリティ担当者・管理者)は合理的にパッチ優先度を定めることが難しかった。 この混乱を解消すべく、米国 NIAC の提案により2005年に CVSS v1 が公開され、FIRST が運用を引き継いで v2(2007)、v3.0(2015)、v3.1(2019)を経て、2023年11月に v4.0 が発表された。

第二の背景は、脆弱性管理がリスクベース(risk-based)へ移行しているという現実である。 毎年公開される CVE(共通脆弱性識別子)は数万件に達し、組織のパッチ能力ではすべてを同時に対応することはできない。 したがって「何を先に修正するか」を決定する客観的かつ再現可能な基準が必要であり、CVSS はその出発点として脆弱性深刻度を数値化し、優先順位付けの一次的根拠を提供する。

第三の背景は、規制・標準との連携である。 米国 NVD(National Vulnerability Database)がすべての CVE に CVSS スコアを付与し、PCI-DSS のような産業規制が「CVSS 4.0 以上の脆弱性への対処」を要求することで、CVSS は事実上、世界中の脆弱性管理の共通尺度として定着した。 国内でもセキュリティソリューションや脆弱性点検報告書が CVSS を基本指標として採用しており、技術士の観点から必ず習得すべき標準である。

2. CVSS の構造 — メトリクスグループとスコア算定

CVSS の核心は、脆弱性の特性を性格の異なるメトリクスグループに分けて評価する点にある。 グループを分離する理由は、脆弱性の「本質的性質」と「時間とともに変化する性質」、「自組織でのみ有効な性質」を混在させると、スコアの意味が曖昧になるからである。 下の概念図は CVSS(v3.1・v4.0 共通の骨格)の全体メトリクス構造を示す。

flowchart TB
    CVSS["CVSSスコア体系(0.0~10.0)"]
    BASE["基本メトリクス(Base) - 固有・不変の特性"]
    TEMP["脅威/時間メトリクス(Threat·Temporal) - 時間で変化"]
    ENV["環境メトリクス(Environmental) - 組織の文脈を反映"]
    SUPP["補助メトリクス(Supplemental, v4.0) - 参考用(スコア無影響)"]
    CVSS --> BASE
    CVSS --> TEMP
    CVSS --> ENV
    CVSS --> SUPP
    BASE --> EXP["攻撃可能性(AV·AC·PR·UI 等)"]
    BASE --> IMP["影響度(機密性·完全性·可用性)"]

基本メトリクス(Base)は脆弱性自体の変わらない本質的特性を評価し、CVSS スコアの骨格となる。 これはさらに「攻撃可能性(Exploitability)」と「影響度(Impact)」に分かれる。 攻撃可能性は、攻撃者がどれほど容易に脆弱性へ到達できるかを見る軸であり、攻撃経路(AV: Network・Adjacent・Local・Physical)、攻撃複雑度(AC: Low・High)、必要権限(PR: None・Low・High)、利用者関与(UI: None・Required)から構成される。 例えばネットワーク遠隔から(AV:N)特別な条件なく(AC:L)認証なしに(PR:N)利用者の介入なく(UI:N)悪用される脆弱性は攻撃可能性スコアが最大となり、ワーム(worm)のように自己伝播する危険が高まる。

影響度は、脆弱性が成功裏に悪用された際に機密性(C)・完全性(I)・可用性(A)がそれぞれどれほど損なわれるか(None・Low・High)を評価する。 三要素を分離して評価する理由は、情報漏洩(機密性)とデータ改ざん(完全性)、サービス停止(可用性)が組織に与える被害の性格が全く異なるからである。 v3.1 ではここに範囲(Scope)の概念を置き、脆弱な構成要素の被害がセキュリティ権限境界を越えて他の構成要素まで波及するか(Changed/Unchanged)を反映した。例えばハイパーバイザー脆弱性でゲスト VM からホストまで掌握されれば Scope が Changed となり、スコアが大きく上昇する。

時間/脅威メトリクスは、時間とともに変化する特性を補正する。 v3.1 の Temporal グループは攻撃コード成熟度(E)、治療水準(RL)、報告信頼度(RC)から構成され、PoC のみ存在するか実際のエクスプロイトが公開されたかによって危険度が変わることを表現する。 v4.0 はこれを脅威(Threat)メトリクスへ簡素化し「攻撃成熟度(E)」一つのみを残したが、これは後述する EPSS のような外部脅威情報と役割が重なるという判断による。

環境メトリクス(Environmental)は、同一の脆弱性であっても自組織の環境における実際のリスクが異なるという点を反映する。 資産の機密性・完全性・可用性の重要度(セキュリティ要求事項 CR・IR・AR)を加重し、組織が既に適用した緩和策に応じて基本メトリクスを修正(Modified Base)できる。 例えばインターネットに露出していない閉域網の DB 脆弱性は攻撃経路が事実上制限されるため、環境スコアを低く調整するのが合理的である。

スコアは攻撃可能性・影響度の下位スコアを定められた式で合算し 0.0~10.0 として算出し、これを等級へマッピングする。 下の表は v3.1/v4.0 共通の深刻度等級区分である。

3. リスクベースの優先順位付けと EPSS・KEV 連携

CVSS スコアのみでパッチ順序を定める方式には構造的な限界がある。 CVSS 基本スコアは「どれほど深刻になりうるか(severity)」を測るが、「実際に攻撃される可能性がどれほどあるか(likelihood)」は語らない。 NVD の統計を見ると公開 CVE の相当数が High・Critical に偏っており、基本スコアのみを基準とすると「危険なものだらけ」となり、優先順位付け機能が事実上麻痺する。実際、全公開脆弱性のうち実際の攻撃に活用される割合は一桁パーセントに過ぎないという研究が繰り返し報告されている。

この限界を補うため、現代の脆弱性管理は CVSS を EPSS・KEV・資産文脈と結合する。 EPSS(Exploit Prediction Scoring System)も FIRST が運用する体系であり、機械学習モデルで特定の脆弱性が今後30日以内に実際に悪用される確率(0~1)を予測する。CVSS が「被害の大きさ」であれば、EPSS は「悪用の可能性」を補完する軸である。 KEV(Known Exploited Vulnerabilities)は米国 CISA が運用する実際の悪用が確認された脆弱性一覧であり、名が載れば「理論的リスク」ではなく「現在進行形の脅威」であることを意味する。

下のフロー図は、CVSS を出発点として EPSS・KEV と資産文脈を結合するリスクベースの優先順位付けプロセスを示す。

flowchart LR
    A["脆弱性の特定(CVE·スキャナ)"] --> B["CVSS基本スコア算定(深刻度)"]
    B --> C["EPSS適用(悪用確率予測)"]
    C --> D["KEV照会(実際の悪用有無)"]
    D --> E["資産重要度·環境メトリクス反映"]
    E --> F{"リスク優先順位の決定"}
    F -->|"高い"| G["即時パッチ·緩和"]
    F -->|"低い"| H["定期パッチ周期へ編入"]

実務では例えば「CVSS 9.0 以上かつ KEV に登載、または EPSS 0.5 以上」の脆弱性を即時対処対象とし、その他の Critical・High は SLA ベースの定期パッチへ分類する、といった方針を運用する。 こうすれば数千件の Critical の中からも「今まさに危険な」数十件に資源を集中でき、限られたセキュリティ人員の効率が劇的に改善される。

具体的な事例として、2021年の Log4Shell(CVE-2021-44228)は CVSS v3.1 基準で 10.0(Critical)(AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H)であり、遠隔から認証なしに任意コード実行が可能で影響が他システムまで波及し(S:C)最高点を得て、公開直後に KEV へ即時登載され、世界中が緊急対応に入った。 逆に CVSS は高いが EPSS・KEV が低い脆弱性も多く、三指標を併せて見ることが過大・過小対応をいずれも避ける道である。

4. バージョン比較 — v3.1 と v4.0、類似体系

CVSS v4.0 は v3.1 に提起された批判を正面から受け入れて改編された。 最大の変化は範囲(Scope)メトリクスの廃止であり、曖昧だとの指摘が多かった Scope の代わりに、脆弱システム影響(VC·VI·VA)と後続システム影響(SC·SI·SA)を明示的に分離して被害伝播をより精密に表現する。 また攻撃成功に特定の条件が必要かを見る攻撃要求事項(AT)メトリクスが新設され、利用者関与(UI)が None・Passive・Active に細分化された。

第二の変化は補助メトリクス(Supplemental)グループの追加である。 安全(Safety)・自動化可能性(Automatable)・復旧(Recovery)・価値密度(Value Density)など運用判断に役立つ情報を含めつつ、スコアには影響を与えない参考用指標として置いた点が特徴である。 第三に v4.0 は命名規則を導入し、CVSS-B(基本のみ)、CVSS-BT(基本+脅威)、CVSS-BE(基本+環境)、CVSS-BTE(全体)のようにどのメトリクスまで反映したスコアかを透明に表記するようにした。これは「大半の組織が基本スコアのみを用い、時間・環境メトリクスを活用しないためスコアが過大評価される」という長年の批判への応答である。

CVSS は CVE・CWE・EPSS など他のセキュリティ標準と役割が区分される。 CVE が「どの脆弱性か(識別)」、CWE が「どの類型の欠陥か(分類)」を扱うのに対し、CVSS は「どれほど深刻か(評価)」を担当する。 また供給網セキュリティでは [[sbom]] で構成要素を把握し、[[vex-vulnerability-exploitability-exchange]] で「その脆弱性が自製品に実際に影響するか」を判別した上で、CVSS で深刻度を付けるというように、複数の標準が鎖のように連携する。

5. 深化: 最新動向と実務適用

近年の脆弱性管理のパラダイムは「深刻度中心」から「攻撃可能性・露出中心」へ移行している。 これは CVSS 単独使用の限界が広く認識された結果であり、ガートナー等は組織が CVSS・EPSS・脅威インテリジェンス・資産重要度を統合したリスクベース脆弱性管理(RBVM)と継続的脅威露出管理(CTEM)へ転換するよう勧告してきた(詳細な数値・時点は報告書の版ごとに異なるため一般化して理解すべきである)。 実際、米国政府の SSVC(Stakeholder-Specific Vulnerability Categorization)のように、スコア一つで並べる代わりに「悪用有無・自動化可能性・任務影響」を問答式で判断して対処/追跡/注視などに分類する意思決定モデルも拡散している。

実務適用の事例として、大型金融会社やクラウド事業者は数万台の資産のスキャナ結果に CVSS 基本スコアを基本フィルタとしてかけ、その上に EPSS 確率と KEV 登載有無を結合した加重リスクスコアを自社で算出し、パッチ SLA(例: KEV 登載は24時間、Critical は7日、High は30日)を運用する。 こうすれば CVSS が生み出した数千件の Critical の山から抜け出し、実際に組織に脅威となる少数に集中できる。 また [[devsecops]] パイプラインでは、ビルド段階の依存性スキャン結果に CVSS 閾値(例: 7.0 以上発見時にビルド遮断)ゲートをかけ、脆弱性が運用に反映される前に選別する方式で活用する。

出題の観点から CVSS は「脆弱性評価・管理体系を説明せよ」「リスクベース脆弱性管理の方策」「CVSS の限界と補完方策(EPSS・KEV 連携)」といった設問と強く連携する。 答案構成の際は、(1) CVSS メトリクス構造(基本・脅威・環境)で概念を定義し、(2) v4.0 の改善点で最新性を示し、(3) CVSS 単独使用の限界を指摘し、(4) EPSS・KEV・資産文脈を結合したリスクベースの優先順位付けで実務的解法を提示する流れが効果的である。

6. 考慮事項および示唆

技術士の観点から CVSS は「スコアそれ自体」ではなくリスクベース意思決定の入力値として扱うべきであり、以下を総合的に考慮する。

• 適用戦略(単独使用の禁止): CVSS 基本スコアのみで優先順位を定めると過度な Critical の山に圧倒されるため、EPSS(悪用確率)・KEV(実際の悪用)・資産重要度を結合したリスクベース脆弱性管理(RBVM)方針を策定し、組織特性に合った環境メトリクスを必ず反映すべきである。
• トレードオフ(精密性 vs 運用コスト): 時間・環境メトリクスまで精密に評価すればスコアの現実性は高まるが、資産ごとの手作業負担が増す。全社一括の精密評価は非現実的であるため、中核資産・外部露出区間から選別的に深層評価し、残りは自動化された基本スコアで管理する階層的アプローチが現実的である。
• スコアインフレ・誤用への警戒: CVSS は「最悪のシナリオ」を仮定して設計されスコアが高く出る傾向があり、ベンダーが責任回避のため故意にスコアを膨らませたり下げたりする歪みも発生する。したがって NVD・ベンダースコアを盲信せず自社の環境メトリクスで再評価し、v4.0 の CVSS-BTE 表記のようにどのメトリクスまで反映したスコアかを確認すべきである。
• ガバナンス・規制整合性: PCI-DSS 等の規制が要求する CVSS 閾値をパッチ SLA・[[isms-p]] 統制項目と整合するよう設計し、脆弱性対処履歴と根拠(スコア・EPSS・KEV)を記録して監査追跡性を確保すべきである。
• 展望・連携技術: CVSS は [[sbom]]・[[vex-vulnerability-exploitability-exchange]]・[[mitre-attack]]・[[threat-modeling]] と結合する際に供給網全体のリスクを体系的に扱え、今後 SSVC・CTEM のような意思決定中心モデルと AI ベースの悪用予測が結合して「スコアの並べ替え」を超えた文脈認知型リスク管理へ進化すると展望される。

参考資料

• FIRST, "CVSS v4.0 Specification Document". https://www.first.org/cvss/v4-0/specification-document
• FIRST, "Common Vulnerability Scoring System SIG". https://www.first.org/cvss/
• FIRST, "EPSS — Exploit Prediction Scoring System". https://www.first.org/epss/
• CISA, "Known Exploited Vulnerabilities Catalog". https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• NIST NVD, "Vulnerability Metrics". https://nvd.nist.gov/vuln-metrics/cvss

一言まとめ: CVSS は FIRST が管理する標準脆弱性深刻度評価システムであり、基本・脅威・環境メトリクスで 0.0~10.0 のスコアを算出するが、深刻度のみを測る限界を EPSS(悪用確率)・KEV(実際の悪用)・資産文脈と結合したリスクベースの優先順位付けで補完してこそ実務的価値を持つ。