CVSSとは？スコアの見方と対応優先度の決め方

CVSSとは

CVSSはCommon Vulnerability Scoring Systemの略称である。 情報システムの脆弱性の深刻度を数値化する共通規格だ。 米国の非営利団体FIRSTが仕様を策定し、維持管理を担う。 日本の公開情報ではIPAやJVNがCVSS値を付与して広報する。 仕様の一次情報はFIRSTの公開文書にある（https://www.first.org/cvss/）。 バージョンはv2、v3.0、v3.1、v4.0が存在する。 2026年10月時点の実務ではv3.1とv4.0が併存する。 v3.1は2019年6月に公開され、長く標準として使われた。 v4.0は2023年11月に公開され、評価項目が拡張された。

CVSSの目的は、脆弱性ごとの危険度を比較可能にすることだ。 ベンダーや研究機関が異なる表現を用いても、共通尺度で判断できる。 数値は0.0から10.0の範囲で算出される。 数値が高いほど深刻度が高いことを示す。 ただし業務影響の大きさを直接示す指標ではない。 攻撃成立のしやすさと情報資産への技術的影響を測る物差しだ。

スコアを構成する3つの評価基準

CVSS v3.1は基本評価、現状評価、環境評価の3層で構成される。 基本評価は脆弱性固有の特性を測る。 時間が経過しても変化しない技術的要素が対象だ。 現状評価は攻撃コードの流通状況や修正の有無を反映する。 環境評価は利用者側の資産重要度や対策状況を反映する。 公開されるNVDの値は基本評価値が中心である。 JVNやベンダーが現状評価や環境評価を付す場合もある。

基本評価の主な測定項目は8つある。 攻撃元区分、攻撃条件の複雑さ、必要な特権、利用者の関与の有無である。 さらに適用範囲、機密性、完全性、可用性への影響を加える。 攻撃元区分はネットワーク、隣接、ローカル、物理の4段階だ。 ネットワーク経由で悪用可能な脆弱性は高く評価される。 特権不要かつ利用者の操作不要な条件は最高水準の危険とみなす。

現状評価は3項目で構成される。 攻撃コードの成熟度、修正レベル、報告の信頼性だ。 実証コードが公開されると値は上昇する。 公式修正が提供されると値は低下する。 環境評価は資産の機密性要求度などを加味する。 同じ脆弱性でも金融機関と閉域網の工場では意味が変わる。 その差を数値に反映する仕組みだ。

v4.0では体系が整理され、基本、脅威、環境、補足に分かれた。 攻撃要件、安全影響、自動化可否などの観点が追加された。 医療機器や産業制御装置の安全被害を区別できる。 粒度が上がった分、評価者の習熟が求められる。 移行期のため、v3.1との併記が当面続く見通しだ。

スコアの見方と深刻度区分

深刻度は数値帯で5段階に区分される。 0.0はなし、0.1〜3.9は低、4.0〜6.9は中だ。 7.0〜8.9は高、9.0〜10.0は緊急に分類される。 区分はNVDの運用（https://nvd.nist.gov/vuln-metrics/cvss）で定着した。 JVNデータベース（https://jvndb.jvn.jp/）もこの区分を用いる。

評価結果はベクトル文字列で表記される。 一例として、CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:Hを示す。 攻撃元がネットワークで条件が単純な状態だ。 特権不要で利用者の関与も不要である。 機密性、完全性、可用性の喪失がいずれも大きい。 この組み合わせは9.8となり、緊急に区分される。

数値だけを見て即時対応を決める運用は危険だ。 7.5でも外部公開装置なら即時対応が必要になる。 9.8でも隔離網内で悪用経路がなければ順位は下がる。 ベクトル文字列まで読み、悪用経路を確認する習慣が重要だ。 特に攻撃元区分と特権、利用者関与の3点は優先して確認する。

CVE・CWEとの違い

CVE、CWE、CVSSは役割が異なる。 CVEは個々の脆弱性に付与される識別番号だ。 CWEは脆弱性の種類を示す弱点分類だ。 CVSSは脆弱性の深刻度を示す評価値だ。 3者は補完関係にあり、置換はできない。

代表例としてLog4Shellが挙げられる。 識別番号はCVE-2021-44228である。 弱点分類はCWE-502の信頼できないデータのデシリアライゼーションだ。 CVSS v3.1の基本値は10.0と算出された。 CVEで対象を特定し、CWEで原因類型を把握する。 CVSSで対応順位を決める流れが実務の基本だ。

実務文書での使い分けは明確だ。 資産台帳にはCVE番号を記録する。 設計指針やコード規則にはCWE番号を引用する。 月次報告や対応指示にはCVSS値を添える。 3点を併記すると手戻りが減る。 ベンダー通知とNVDの値が異なる場合、両方を残すと原因追跡が容易だ。

脆弱性対応の優先順位付けの実務

現場ではCVSS値を入口の選別に用いる。 その後に資産重要度と悪用可能性を掛け合わせる。 手順は4段階が定石だ。 第一に資産台帳と公開範囲を突き合わせる。 第二にCVSS値で一次選別する。 第三に悪用観測と到達可能性で補正する。 第四に対応期限と担当を割り当てる。

一次選別の目安は組織ごとに定める。 一例では緊急を24時間以内着手、高を7日以内着手とする。 中は30日以内、低は次回保守時とする。 ただし外部公開の認証不要の管理画面などは引き上げる。 閉域網で多要素認証がある場合は引き下げる。 一律の数値運用は誤対応を招く。

悪用可能性の補完指標が重要だ。 EPSSは今後30日以内の悪用確率を示す。 CISAのKEV一覧は実際に悪用が確認された脆弱性の目録だ。 KEV掲載品はCVSS値にかかわらず最優先とする組織が多い。 SSVCは悪用状況と人命影響から対応を判定する枠組みだ。 CVSS、EPSS、KEVの3点照合が現実的な解だ。

運用を回す要点は記録の残し方にある。 CVE番号、CVSS値、ベクトル、資産名、公開範囲を1行にまとめる。 対応不要と判断した場合も理由を残す。 VEX文書で修正不要や影響なしを宣言する手法も普及した。 SBOMと組み合わせると影響範囲の特定が速くなる。 監査対応でも説明責任を果たせる。

CVSSの限界と誤用防止

CVSSは業務文脈を反映しない。 売上影響や復旧費用は測定対象外だ。 攻撃コード公開前の値は実害より低く出る場合がある。 評価者により0.5程度のぶれが生じる。 ベンダー値とNVD値が食い違う主因だ。

よくある誤用は3つある。 第一に中と低の放置である。 連鎖で高に転じる組み合わせが存在する。 第二に基本値だけでの一律起票である。 環境評価を怠ると対応が破綻する。 第三にv3.1とv4.0の混同である。 項目が異なるため単純比較はできない。 バージョン明記を徹底する必要がある。

編集部の見解

比較時の評価軸は、基本値の高低ではなく自社資産への波及度と悪用可能性で判断すべきと見る。CVSSは攻撃成立条件を示すが、業務停止時間や情報漏えい量は示さない。EPSSやKEV登録状況と組み合わせた評価を重視すべきと評価する。 現場での落とし穴は、ベンダー算出値とNVD算出値の差異放置にある。評価者によって前提条件が変わり、同一CVEで0.5以上の差が出る事例がある。安易な自動起票ではなく、環境評価値で補正する運用が不可欠と見る。 今後の方向性は、CVSS v4.0とSSVCやVEXの併用が標準化に向かうと言えそうだ。SBOM普及で資産特定が高速化し、深刻度と到達可能性の掛け合わせが主流になる。単一指標依存から複合判断への移行が進むと見る。

参考

• FIRST CVSS v3.1 Specification (https://www.first.org/cvss/v3.1/specification-document)
• FIRST CVSS v4.0 Specification (https://www.first.org/cvss/v4.0/specification-document)
• NVD Vulnerability Metrics, NIST (https://nvd.nist.gov/vuln-metrics/cvss)
• JVNデータベース (https://jvndb.jvn.jp/)
• IPA 脆弱性対策情報 CVSS関連 (https://www.ipa.go.jp/security/vuln/CVSS.html)
• CISA Known Exploited Vulnerabilities Catalog (https://www.cisa.gov/known-exploited-vulnerabilities-catalog)