CVSSとは？ わかりやすく10分で解説

UnsplashのAmperが撮影した写真

CVSSは、脆弱性の深刻度を共通の基準で数値化するための枠組みです。現場でまず押さえたいのは、CVSSが示すのは「技術的な深刻度」であって、組織にとっての最終的なリスクではないという点です。対応順を決めるときは、CVSSを起点にしつつ、公開範囲、資産の重要度、実際の悪用状況、回避策の有無を重ねて判断します。

そのため、CVSSスコアだけを見て「9点台だから即時対応」「5点台だから後回し」と決める運用は粗すぎます。外部公開された認証基盤の6点台と、社内限定の検証環境にある8点台では、優先順位が逆転することがあります。CVSSは優先順位づけの土台として使い、最終判断は自社環境の条件で補正する方が扱いやすくなります。

CVSS（Common Vulnerability Scoring System）とは

CVSSは、脆弱性の特性と影響を共通の尺度で表すためのスコアリング方式です。ベンダーや製品が異なっても、同じ考え方で深刻度を比較しやすくするために使われます。脆弱性情報の一覧から対応候補を絞る場面や、関係部署へ対応理由を説明する場面で使われることが多くなります。

スコアは0.0から10.0で表されます。数値が高いほど、一般には技術的な深刻度が高いと読みます。ただし、CVSSは「その脆弱性がどれだけ危険な性質を持つか」を表すもので、組織の業務影響や停止許容までは自動で反映しません。

CVSSで分かることと、分からないこと

分かること

• 攻撃がどこから成立し得るか
• 認証や利用者操作などの前提が必要か
• 機密性、完全性、可用性へどの程度影響し得るか
• 同じ尺度で深刻度を比較するための基礎情報

分からないこと

• その資産が自社でどれだけ重要か
• 外部公開されているか、内部限定か
• 実際に悪用が始まっているか
• パッチ適用でどれだけ停止影響が出るか
• 回避策や防御策が現場でどこまで効いているか

この差を理解していないと、CVSSを「リスクそのもの」と誤読しやすくなります。CVSSはあくまで共通の物差しであり、業務判断そのものではありません。

CVSSのバージョンはなぜ確認が要るのか

CVSSは改訂を重ねており、同じ脆弱性でも評価バージョンが違うと見え方が変わることがあります。特に実務でよく参照されるのはCVSS v3.1とv4.0です。

• CVSS v3.1：Base、Temporal、Environmental の3群で構成されます。
• CVSS v4.0：Base、Threat、Environmental、Supplemental の4群で構成されます。

v4.0では、ThreatがTemporalに代わる形で整理され、Supplementalが追加されました。Supplementalは補足情報を表すための群で、最終スコア自体は変えません。したがって、CVSSを見るときは「何点か」だけでなく、「どのバージョンの、どのベクターで評価されているか」まで確認した方が解釈を誤りにくくなります。

CVSSの主な評価基準

Base Metrics

Baseは、脆弱性そのものが持つ技術的な性質を評価する群です。攻撃元、攻撃の成立条件、必要な権限、利用者操作の有無、そしてCIAへの影響がここに入ります。一次仕分けでは、まずBaseを確認すると全体像をつかみやすくなります。

Temporal / Threat

CVSS v3.1ではTemporal、v4.0ではThreatが、時間とともに変わる要素を扱います。たとえば、PoCの公開、悪用の観測、対処手段の有無といった事情です。同じ脆弱性でも、攻撃コードが出回った後では緊急度が変わるため、この群を無視すると初動が遅れやすくなります。

Environmental

Environmentalは、自組織の環境での影響を反映する群です。外部公開、内部限定、重要資産、抑止策の有無といった条件を反映しやすいため、対応順の最終調整ではここが効きます。実務では、CVSSの標準項目に加えて、独自の資産重要度や停止許容も併せて扱うことが多くなります。

Supplemental

v4.0で追加されたSupplementalは、脆弱性の追加的な特徴を伝えるための補足情報です。数値そのものを変える群ではありませんが、運用担当が remediation の計画を立てる際には参考になります。数値だけでなく、ベクター全文を確認した方が判断材料が増えます。

CVSSスコア帯の読み方

CVSSでは、一般に次の深刻度帯が使われます。

1. 0.0：None
2. 0.1〜3.9：Low
3. 4.0〜6.9：Medium
4. 7.0〜8.9：High
5. 9.0〜10.0：Critical

この帯は便利ですが、同じHighでも性質はかなり違います。無認証で外部から到達できる7点台と、ローカル権限が前提の8点台では、初動で取る対策が変わります。スコア帯は目安として使い、必ずベクターの中身まで読みます。

CIAの見方

CVSSでは、CIAへの影響が深刻度の中核に入っています。

• 機密性：本来見られるべきではない情報が漏れるか
• 完全性：データや設定が改ざんされるか
• 可用性：サービス停止や性能劣化が起きるか

ここで見落としやすいのは、どの要素が業務にとって最も痛いかは組織ごとに違うことです。個人情報を扱うサービスでは機密性の影響が重く、工場や医療のような領域では可用性の比重が上がることがあります。CVSSが示す技術影響を、そのまま業務影響に読み替えない方が安全です。

CVSSを使った優先順位づけ

優先順位づけを安定させるなら、少なくとも次の4点をCVSSに重ねます。

• 露出範囲：インターネット公開か、内部限定か
• 資産重要度：認証基盤、決済、顧客情報、基幹業務に関わるか
• 実悪用状況：悪用観測や攻撃コード公開があるか
• 対処可能性：パッチ、設定変更、遮断、緩和策のどれが使えるか

たとえば、公開サーバー上のMediumは短期対応に上がることがありますし、停止影響が大きいHighは回避策を先に入れて計画停止で直すこともあります。CVSSだけで順序を固定すると、こうした現実の差を吸収しにくくなります。

CVSSを使うメリット

一次トリアージが速くなる

脆弱性が多い環境では、全件を同じ熱量で検討するのは無理があります。CVSSを起点にすると、まず見るべき候補を絞りやすくなります。

説明の共通言語になる

開発、運用、セキュリティ、経営層、委託先で認識を揃えるときに、CVSSは説明の土台になります。「なぜ今これを優先するのか」を数値とベクターで示しやすくなるためです。

独自基準を重ねやすい

CVSSは公開仕様なので、資産重要度や停止許容のような独自ルールを上に重ねやすくなります。標準スコアと自社事情を分けて扱えるため、後から見直しやすい形で残せます。

CVSSだけに頼ると起きやすい問題

高スコアだけを機械的に追う

高スコアの脆弱性ばかりを追うと、外部公開された中スコアの穴や、既に悪用されている低めの脆弱性を取りこぼすことがあります。

対処コストを見ない

パッチを当てれば直る脆弱性でも、停止影響や検証工数が大きければ、そのまま即時適用できるとは限りません。短期は緩和策、中期で恒久対処という分け方が必要になることがあります。

バージョンを混在させる

v3.1とv4.0を区別せずに一覧へ並べると、評価軸の違いを見落としやすくなります。運用ルールの中で、どの版を主軸にし、混在時にどう扱うかを決めておく方が整理しやすくなります。

まとめ

CVSSは、脆弱性の技術的な深刻度を共通の尺度で表すための枠組みです。対応順を決める起点としては有用ですが、それだけで組織のリスク判断を完結させることはできません。スコア、ベクター、公開範囲、資産重要度、実悪用状況、対処可能性を重ねて見ていくと、優先順位づけの精度が上がります。

実務では、まずCVSSで一次仕分けし、その後に自社環境で補正する流れが扱いやすくなります。CVSSを絶対評価として扱うのではなく、説明可能なトリアージの土台として使う方が判断を誤りにくくなります。