CVSSとは｜脆弱性の深刻度評価と対応優先度の決め方

CVSSとは｜脆弱性の深刻度を数値化する共通指標

CVSS（Common Vulnerability Scoring System／共通脆弱性評価システム）は、ソフトウェアの脆弱性がどれくらい深刻かを、ベンダーや国を越えて同じ物差しで表すための標準です。 評価結果は0.0〜10.0のスコアと、評価の内訳を表すベクトル文字列の2つで表現されます。

同じ脆弱性でも、製品ベンダーが「重大」と呼び、別の会社が「中程度」と呼ぶ状態では議論になりません。共通の採点ルールを決めて、誰が採点しても近い数字になるようにしたのがCVSSです。

管理しているのはFIRST

CVSSの仕様を策定・改訂しているのは、インシデント対応チームの国際団体であるFIRSTです。バージョンの変遷は次のとおりです。

v1からv2への移行経緯はIPAの「共通脆弱性評価システムCVSS概説」にもまとめられています。なお現在も、脆弱性情報サイトによってはv3.1のスコアが主に掲載されているため、「どのバージョンの何点か」をセットで確認する習慣が要ります。

CVSSが答えること、答えないこと

CVSSが答えるのは「この脆弱性は、突かれたらどれくらい影響が出るか」です。逆に、次の問いには答えません。

• その脆弱性が、自社の環境で実際に悪用される可能性はどれくらいか

• 影響を受ける資産が、インターネットに露出しているのか社内の閉じた環境なのか

• その資産が止まったときに、事業としてどれだけ困るのか

この区別は、FIRSTのCVSS v4.0 User Guideに「CVSS Base Score (CVSS-B) Measures Severity, not Risk」という見出しで明記されています。深刻度とリスクは別物だ、という宣言が公式文書に置かれている点は押さえておきたいところです。

CVE・JVN iPediaとの関係

混同されやすい用語を整理します。

CVEが「背番号」、CVSSが「評価点」、NVDやJVN iPediaが「それらを載せた名簿」という関係です。

ミニFAQ：CVSSのスコアは誰が付けるのですか。

製品ベンダー、脆弱性情報の調整機関、脆弱性データベースの運営者など、複数の主体が付けます。そのため同じCVEでも掲載元によってスコアが食い違うことがあります。後述するように、どのソースの値を基準にするかは運用側で決めておく必要があります。

CVSSスコアの読み方｜0.0〜10.0と5段階の深刻度

結論から言うと、スコアは0.0〜10.0で、7.0以上がHigh、9.0以上がCriticalです。 定性的重大度レーティングの区分はCVSS v4.0仕様書で次のように定義されています。

日本語の脆弱性情報サイトやベンダー公表資料では、この5段階に「緊急」「重要」「警告」「注意」といった日本語表記を当てることがあります。社内規程を作る際は、英語表記とスコア範囲のどちらを正とするかを先に決めておくと、表記揺れによる混乱を防げます。

ベクトル文字列の読み下し

スコアと一緒に、評価の内訳を表すベクトル文字列が公開されます。CVSS v4.0仕様書に載っている例は次のような形です。

CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N

スラッシュ区切りの各項目を、先頭から順に読み下すとこうなります。

この例は「ネットワーク経由で狙えるが、高い権限を持っていないと成立せず、影響も限定的」と読めます。スコアの数字だけ見るより、ベクトルを読んだほうが自社に効くかどうかの判断が早いのが実際のところです。採点をやり直したいときはFIRSTが公開しているCVSS計算機で値を変えながら試せます。

CVSS v4.0の評価基準とv3.1からの変更点

CVSS v4.0は、4つのメトリックグループで構成されます。 必須なのは基本評価基準だけで、残りの3つは任意です。

基本評価基準（Base Metrics）

脆弱性そのものが持つ、時間や環境で変わらない特性を評価します。v4.0では11項目で構成されます。

• 悪用のしやすさ：AV（攻撃元区分）、AC（攻撃条件の複雑さ）、AT（攻撃要件）、PR（必要な特権レベル）、UI（利用者の関与）

• 影響度：VC／VI／VA（脆弱性のあるシステムへの影響）、SC／SI／SA（後続システムへの影響）

脅威評価基準（Threat Metrics）

時間とともに変わる要素を反映する任意のグループで、v4.0ではE（Exploit Maturity＝攻撃コードの成熟度）の1項目に集約されました。攻撃が観測されているのか、PoC止まりなのか、報告がないのかを反映します。

環境評価基準（Environmental Metrics）

利用者側が、自社環境に合わせてスコアを補正するためのグループです。 セキュリティ要求度（CR／IR／AR）と、基本評価基準を自社条件で上書きするModified系メトリクス（MAV、MAC、MPR、MVC など）で構成されます。

実務で最も活用余地があるのに、最も使われていないのがここです。たとえば「DBサーバは社内ネットワークからしか到達できない」なら攻撃元区分を下げられますし、「可用性より機密性が重要」ならCRを上げられます。

補足評価基準（Supplemental Metrics）

v4.0で新設されたグループで、S（Safety＝人の安全への影響）、AU（Automatable＝攻撃の自動化可能性）、R（Recovery＝復旧性）、V（Value Density）、RE（対応にかかる労力）、U（提供元が示す緊急度）の6項目があります。スコアの計算には影響せず、判断材料として添える情報という位置づけです。

CVSS-B／BT／BE／BTEという命名ルール

どのグループまで使って採点したかを明示するため、v4.0では呼び分けが導入されました。

同じ「7.5点」でも、CVSS-Bの7.5とCVSS-BTEの7.5では意味がまるで違います。ユーザーガイドは、脅威情報と環境情報を足したCVSS-BTEであれば「リスクにかなり近い」と言える、という趣旨の説明をしています。公開情報として出回っている数字のほとんどはCVSS-Bだ、という前提は覚えておいて損がありません。

v3.1からv4.0への主な変更点

執筆時点でCVSS v4.0仕様書から確認できる主な差分は次のとおりです。

仕様書によれば、v4.0ではスコアの算出方式も見直され、メトリクスの組み合わせを等価クラスにまとめるMacroVector方式が採られています。手計算で追うのは現実的ではないため、スコアの再計算は公式計算機に任せるのが実務的です。

ミニFAQ：v3.1のスコアはもう使えないのですか。

使えます。v4.0の公開後も、v3.1のスコアを主に掲載している脆弱性情報源は残っています。問題は混在することのほうで、社内の台帳では「v3.1で7.5」「v4.0で8.1」のようにバージョンを添えて記録するのが安全です。

CVSSスコアだけで対応優先度を決めてはいけない理由

スコア順に直すルールは、一見わかりやすいのですが、運用に乗せると破綻します。 理由は3つあります。

理由1：High以上が多すぎて絞れない

中規模のWebアプリと依存ライブラリをスキャンすれば、High以上が数十件から数百件単位で出ることは珍しくありません。「7.0以上は全部直す」という規程は、件数が一定を超えた瞬間に実行不能になります。結果として、規程が形骸化し、誰も台帳を見なくなります。

理由2：公式ガイドが「深刻度≠リスク」と明記している

繰り返しになりますが、FIRSTのユーザーガイドは基本値だけでリスクを評価しないよう求めています。基本評価基準は、脆弱性そのものの性質しか見ていません。自社でその資産がどう使われているかという情報は、最初から入っていないのです。

理由3：実際に悪用される脆弱性はごく一部

公開された脆弱性のうち、現実に攻撃へ使われるものは限られます。だからこそCISAは、実際に悪用が確認された脆弱性だけを集めたKnown Exploited Vulnerabilities（KEV）カタログを公開し、「組織は脆弱性管理の優先順位付けのインプットとしてKEVカタログを使うべき」と明示しています。深刻度の高さと、狙われやすさは一致しません。

対応優先度の決め方｜CVSS・KEV・EPSS・資産露出の4軸トリアージ

実務でやるべきは、CVSSを捨てることではなく、CVSSに3つの軸を足すことです。

軸1：KEV（すでに悪用されているか）

CISAのKEVカタログに載っているCVEは、実際に悪用が確認されたものです。掲載の有無は0か1かで判定でき、解釈の余地がありません。最初のふるいとして最も扱いやすい軸です。

軸2：EPSS（今後30日で悪用される確率）

EPSS（Exploit Prediction Scoring System）は、FIRSTが公開している機械学習ベースのスコアです。公式ページの定義では、公開済みのCVEが今後30日間に実際に悪用される確率を0〜1の値で推定します。順位を示すパーセンタイルも併せて提供されます。

KEVが「すでに起きたこと」を示すのに対し、EPSSは「これから起きそうか」を示します。両者は競合せず、KEVで即応対象を決め、KEV未掲載の山をEPSSで並べ替えるという使い方が噛み合います。

軸3：資産の露出度と事業影響

同じCVEでも、インターネットに公開されたAPIゲートウェイと、社内の検証用サーバでは緊急度が違います。少なくとも次の3点は台帳に持たせておきたいところです。

• インターネットから到達可能か

• 個人情報・決済情報など、守るべきデータを扱っているか

• 止まったときに事業が止まるか

軸4：CVSSの環境評価基準で自社向けに補正

ここで前述の環境評価基準が効きます。公開されているCVSS-Bのベクトルを計算機に入れ、自社条件でModified系メトリクスを書き換えれば、CVSS-BEとして再採点できます。「公開スコアは9.8だが、当該サーバは社内限定なので自社では6.1」という形で、判断の根拠を数字と一緒に残せるのが利点です。

4軸を組み合わせた優先度判定の目安

以下は、上記4軸を実際のトリアージに落とし込むときの整理例です。社内規程を作るときのたたき台として使ってください。期限の数値は組織の体制によって変わるため、自社のリリースサイクルに合わせて調整する前提の目安です。

最後の行が実は一番重要です。直さない判断をした脆弱性こそ、根拠を書き残しておかないと、監査や客先レビューで説明できなくなります。

2026年の潮流：CISA BOD 26-04が示した判断軸

この「CVSS一本から多軸へ」という流れは、政府調達の世界でも明確になりました。

はじめに適用範囲を整理します。以下で取り上げるBOD 26-04は、米国の連邦民間行政機関（FCEB）に対する拘束力のある指令であり、日本の民間企業に直接適用されるものではありません。 ここでは義務として紹介するのではなく、脆弱性管理規程を設計するときの判断軸の実例として読んでください。

CISAが2026年6月10日に発行したBOD 26-04「Prioritizing Security Updates Based on Risk」は、対象機関に対し、脆弱性の対応優先度を次の4つの基準で判断するよう求めています。

• 資産の露出状況：その資産がインターネットに公開されているか

• KEVへの登録状況：当該CVEがKEVカタログに載っているか

• 悪用の自動化可能性：攻撃に必要な手順を攻撃者が自動化できるか

• 悪用後の技術的影響：攻撃者が部分的な制御を得るのか、完全な制御を得るのか

最もリスクが高い条件（KEV掲載・公開露出・自動化可能・完全制御）に該当する場合は、3日以内という短い期限が設定されています。リスクが下がるほど期限が延びる段階設計です。このディレクティブは、従来KEVの対応期限を定めていたBOD 22-01を廃止したうえで置き換えたものです。期限の正確な区分は原文のTable 1を参照してください。

注目すべきは、この優先度判定がCVSSスコアではなく、CMU SEIとCISAが開発したSSVC（Stakeholder-Specific Vulnerability Categorization）を土台にしている点です。SSVCは悪用状況・技術的影響・自動化可能性・ミッションへの影響度・公共の福祉への影響といった決定ポイントをたどり、Track／Track（星付き）／Attend／Actの4区分を出力する決定木モデルです。Trackは通常の更新サイクルで対応、Attendは標準より早い対応、Actは可能な限り迅速な対応を意味します。

自社の規程に取り込むなら、期限の日数をそのまま写すのではなく、4つの判断基準の組み合わせ方だけを借りるのが現実的です。日数は自社のリリースサイクルと要員体制で決まるためです。

日本の現場でCVSSはこう使われる

日本企業の現場では、CVSSは「スキャナの出力」としてよりも、「契約と報告書に出てくる数字」として立ち現れます。

JVN iPediaの引き方とスコアの食い違い

IPAとJPCERT/CCが運営するJVN iPediaは、日本語で脆弱性対策情報を検索できるデータベースです。2026年10月時点で確認したところ、一覧にはCVSSv3の値で深刻度が表示されています。

ここで実務的な落とし穴があります。同じCVEでも、JVN iPediaに載っている値と、海外のデータベースやベンダー公表値が一致しないことがあるのです。採点した主体が違えば、メトリクスの解釈も変わるためです。

対策は単純で、社内規程の中で「基準とするソースを1つ決める」こと。「原則としてJVN iPediaの値を使い、未掲載の場合はベンダー公表値を使う」といった形で明文化しておけば、報告のたびに揉めずに済みます。脆弱性対応のリスク評価手法については、IPAが「脆弱性対応におけるリスク評価手法のまとめ」という資料も公開しています。

契約・SLAの「CVSS 7.0以上は◯日以内」条項

受託開発や運用保守の契約書、あるいはセキュリティ要件定義書に、次のような条項が入っていることがあります。

• 「CVSS 7.0以上の脆弱性が発見された場合、受注者は◯営業日以内に対応すること」

• 「Critical相当の脆弱性については、検知から◯時間以内に報告すること」

この条項は、定義が曖昧なまま締結すると後で必ず揉めます。締結前に確認しておきたい点を挙げます。

• CVSSのどのバージョンの値か（v3.1かv4.0か）

• どのソースの値を正とするか（JVN iPedia／NVD／製品ベンダー）

• CVSS-B（基本値）か、環境評価を含めた値か

• 対応の定義は何か（恒久対策までか、回避策の適用までか）

• 保守契約の範囲内の作業か、追加見積もりの対象か

客先のセキュリティ要件への対応は、契約条件そのものに直結します。関連する実務は「客先セキュリティ要件対応｜ISMS・Pマーク・持ち込みPCの実務」でも整理しています。

フリーランスエンジニアがCVSSに向き合う場面

セキュリティ専業でなくても、CVSSの数字を突きつけられる場面は定期的に来ます。 むしろ、開発を担当しているフリーランスのほうが矢面に立ちやすい構図があります。

常駐先・受託先で脆弱性報告を受けたとき

よくあるのは、客先のセキュリティ部門や外部診断ベンダーから「High以上が◯件検出されました。対応方針を出してください」と依頼が来るパターンです。ここで全件を機械的に直そうとすると、工数が溶けます。

必要なのは、件数を優先度で分類し直し、その根拠を説明できる状態を作ることです。前述の4軸で分類したうえで、「この12件は即応、この40件は次回リリース、この88件は該当機能未使用のため対応不要と判断」という形で、理由つきの一覧を返せるかどうかで評価が変わります。

契約外作業との線引きと見積もり

脆弱性対応は、どこまでが契約範囲かが曖昧になりやすい作業です。判断の目安を挙げます。

• 自分が書いたコードの実装不備（SQLインジェクション、XSS など）→ 契約不適合責任の範囲として扱われやすい

• 使用ライブラリの新規脆弱性（公開後に判明）→ 保守契約の有無と条項次第。無償対応の前提にしない

• ミドルウェア・OSの脆弱性 → インフラ運用の担当範囲を契約で確認する

• 恒久対策ではなく回避策の設計・検証 → 工数が読みづらいため、個別見積もりを提案する

実装起因の脆弱性については、「SQLインジェクションとは｜仕組み・主要攻撃4種・実装対策と検知方法」や「XSSとは｜仕組み・3種類の攻撃・実装対策とCSP設計」で対策を確認できます。網羅的なリスク分類は「OWASP Top 10とは｜Webアプリの主要リスク10カテゴリ解説」を参照してください。

脆弱性管理スキルと案件・単価

CVSSの読み方そのものは、半日もあれば身につきます。市場で評価されるのはその先、「大量の検出結果を、説明可能な優先度に落とし込んで運用に乗せられる」という能力のほうです。

具体的には、依存ライブラリのスキャンをCI/CDに組み込み、検出結果をトリアージし、対応状況を台帳として維持する一連の流れです。ツールの使い分けは「SAST・DAST・SCAの違い｜Semgrep／Snykで始めるセキュア開発」、部品表の整備は「SBOMとは｜ソフトウェア部品表の義務化動向と実務対応の手順」が参考になります。管理フレームワークとの接続を知りたい場合は「NIST CSF 2.0とは｜6機能の構成とISMSとの違い」もあわせてどうぞ。

セキュリティ領域の案件単価や、スキル別のレンジ感は「セキュリティエンジニアのフリーランス単価相場｜案件動向とスキル別レンジ」で整理しています。自分の経験でどの程度の単価を狙えるか確かめたい方は、無料のフリーランスエンジニア単価診断で市場単価の目安を確認できます。

脆弱性トリアージ実践チェックリスト

スキャン結果を受け取ってから対応方針を返すまでの流れを、チェックリストにまとめました。

• [ ] 検出されたCVEの一覧を取得し、CVSSのバージョンとスコアのソースを記録したか

• [ ] 各CVEがCISA KEVカタログに掲載されているかを照合したか

• [ ] KEV未掲載のものについて、EPSSの値で並べ替えたか

• [ ] 対象資産のインターネット露出の有無を確認したか

• [ ] 取り扱うデータ（個人情報・決済情報など）の種別を確認したか

• [ ] 該当機能を実際に使用しているかを確認し、未使用なら理由を記録したか

• [ ] 必要に応じて環境評価基準で再採点（CVSS-BE）し、根拠を残したか

• [ ] 即応／次回リリース／定例サイクル／対応不要の4区分に分類したか

• [ ] 対応不要と判断したものに、判断理由を明記したか

• [ ] 契約書・SLAの対応期限条項と、分類結果の整合を確認したか

• [ ] 回避策で凌ぐものについて、恒久対策の実施時期を別途記録したか

分類結果をそのまま客先への報告書に転記できる形にしておくと、同じ作業を二度しなくて済みます。

まとめ

CVSSは脆弱性の深刻度を測る共通の物差しであり、対応の優先度そのものではありません。 深刻度（CVSS）に、悪用の実績（KEV）、悪用される確率（EPSS）、資産の露出度を足して初めて、実務で使える優先度になります。

• CVSSはFIRSTが策定する共通評価システム。執筆時点の最新版はv4.0（2023年11月1日公開）

• スコアは0.0〜10.0の5段階で、7.0以上がHigh、9.0以上がCritical

• 公式ユーザーガイドは「基本値は深刻度であってリスクではない」と明記している

• v4.0ではScopeが廃止され、攻撃要件（AT）と補足評価基準が追加された

• 実務の優先度はCVSS×KEV×EPSS×資産露出の4軸で決める

• CISAのBOD 26-04も、CVSS単独ではなくSSVCベースの多軸判断を採用している

• 契約の「CVSS 7.0以上は◯日以内」条項は、バージョン・ソース・対応の定義を締結前に詰める

次のステップとしては、手元のプロジェクトでSCAツールのスキャンを1回走らせ、検出結果にKEV照合と資産露出の列を足してみてください。優先度が数字の順番どおりにならないことが、すぐに体感できるはずです。

参照した一次情報は次のとおりです。

• FIRST｜Common Vulnerability Scoring System SIG

• FIRST｜CVSS v4.0 Specification Document

• FIRST｜CVSS v4.0 User Guide

• FIRST｜EPSS

• CISA｜Known Exploited Vulnerabilities Catalog

• CISA｜BOD 26-04: Prioritizing Security Updates Based on Risk

• CISA｜Stakeholder-Specific Vulnerability Categorization（SSVC）

• IPA｜共通脆弱性評価システムCVSS概説

• JVN iPedia｜脆弱性対策情報データベース