脆弱性対応の優先順位付け。CVSSだけに頼らないEPSSとCISA KEVの使い方

脆弱性管理を担当していると、毎月のように大量のパッチ情報が降ってきます。スキャナを回せば、High や Critical の脆弱性が数百件、組織によっては数千件単位で一覧に並びます。これを全部当てるのは、現実的には不可能です。人手も検証環境もメンテナンス時間も有限で、「深刻度の高い順に上から潰す」という素朴な運用は、すぐに破綻します。

問題は件数だけではありません。深刻度（CVSS）が高い脆弱性の多くは、実際には悪用されないまま終わります。一方で、深刻度が中程度でも実際に攻撃に使われている脆弱性は確実に存在します。深刻度の高さと、いま本当に危ないかどうかは別の話なのです。限られたリソースを「理論上の最悪」ではなく「現実の危険」へ集中させるには、深刻度だけに頼らない判断軸が要ります。

この記事では、CVSS・EPSS・CISA KEV・SSVC という4つの指標の役割を整理し、それらを組み合わせたリスクベースの優先度付けを、優先度マトリクスと運用ステップに落とし込んで解説します。対象は、脆弱性情報を受け取って自社の対応を判断する脆弱性管理担当・情報システム担当の方です。CVSSそのものの構造や読み方は

まずは4つの指標の役割を整理する#

優先度付けの話に入る前に、登場する指標が「それぞれ何を測っているのか」を切り分けます。ここを混同すると、指標の使い方を誤ります。

ポイントは、CVSSが「その脆弱性がどれだけ危険になりうるか（深刻度）」を表すのに対し、EPSSとKEVは「いま実際に危ないか（悪用の予測と実績）」を表す、という役割の違いです。深刻度・悪用可能性・実際の悪用は、それぞれ別の軸として扱う必要があります。

CVSS: 深刻度の物差し。ただし出発点にすぎない#

CVSS（Common Vulnerability Scoring System、共通脆弱性評価システム）は、脆弱性の深刻度を0.0から10.0の数値で表す、ベンダー非依存の評価手法です。管理母体はFIRSTで、最新版のCVSS v4.0は2023年11月1日に公開されました。深刻度の評語と数値の対応（None/Low/Medium/High/Critical）は広く使われており、対応の議論をするうえでの共通言語になっています。

ここで押さえたいのは、脆弱性情報サイトに「CVSS 9.8」のように出ている数値は、たいてい基本評価基準（Base）だけで算出された値だ、という点です。CVSS v4.0は基本（Base）・脅威（Threat）・環境（Environmental）・補足（Supplemental）の4つの評価グループで構成され、このうち補足はスコアの数値には影響しません。基本値は「脆弱性そのものの理論上の深刻度」であって、「いま実際に攻撃されているか」「自社の環境でどれだけ危ないか」は織り込まれていません。

つまりCVSSの基本値は、優先度付けの出発点としては有用ですが、それ単独で順番を決めるための指標ではありません。FIRSTもv4.0で脅威・環境評価による補正を促していますが、補正には手間がかかり、現実には多くの組織が基本値のまま運用しています。だからこそ、外部から得られる悪用情報（EPSS・KEV）と突き合わせる発想が要ります。CVSS v4.0の構造や、v3.1からの変更点を詳しく知りたい場合は

EPSS: 悪用される確率で大量の脆弱性を絞り込む#

EPSS（Exploit Prediction Scoring System）は、ある脆弱性が今後30日以内に実際に悪用される確率を、0から1の数値で表すデータ駆動の予測モデルです。FIRSTが提供しており、スコアは日次で更新されます。0.9なら「30日以内に悪用される確率が高い」、0.01なら「ほとんど悪用されないと予測される」という意味になります。CVSSの基本値が静的なのに対し、EPSSは新しい脅威情報を反映して日々変わるのが特徴です。

EPSSが効くのは、まさに「全部は当てられない」場面です。CVSSが高い脆弱性は世の中に膨大にありますが、その大半は実際には悪用されません。EPSSで悪用確率の高いものを上位に絞り込めば、限られた人手を「深刻でかつ悪用されやすい」ものへ集中できます。CVSSの縦軸（深刻度）とEPSSの横軸（悪用確率）を掛け合わせると、対応すべき脆弱性が自然に浮かび上がります。

なお、EPSSは2025年3月17日に大幅改良されたv4（モデル版 v2025.03.14）の公開が始まっており、データモデルの精度と悪用活動のリアルタイム追跡が強化されています。スコアはCSVやAPIで無償公開されているため、自社の脆弱性管理ツールやスプレッドシートに取り込んで使えます。

KEV: 実際に悪用された脆弱性は深刻度を問わず最優先#

CISAが公開するKEV（Known Exploited Vulnerabilities Catalog、既知の悪用された脆弱性カタログ）は、実際に攻撃で悪用された証拠がある脆弱性を集めた一覧です。CVSSが「理論上どれだけ深刻か」、EPSSが「悪用される確率」を表すのに対し、KEVは「現実に使われた」という、最も直接的で強い危険信号を提供します。CISAはKEVへの登録基準として、CVE IDが採番されていること、実際の悪用（in the wild）の証拠があること、明確な対策（パッチや緩和策）が存在すること、を挙げています。

実務上の判断はシンプルです。自社が使う製品の脆弱性がKEVに載っているなら、CVSSやEPSSの数値にかかわらず最優先で対応を検討します。CVSSが中程度でも、実際に悪用されているなら放置すべきではありません。KEVは2021年11月に311件で始まり、執筆時点では1,400件を超える規模まで拡大しています（2025年末時点で約1,484件とする集計もある。最新の登録件数はCISAのKEVカタログで確認できる）。

注意したいのは、「KEVに載っていない＝安全」ではないことです。KEVは悪用が確認・公表されたものの一覧であり、まだ観測・公表されていない悪用は当然載りません。KEVは強い加点材料ですが、載っていないことを安全の根拠にはできません。

KEVを起点に米国の連邦方針も「リスクベース」へ動いた#

KEVはもともと、米CISAの拘束的運用指令BOD 22-01（2021年11月）によって、連邦民間機関に期限内の修正を義務づける仕組みとして導入されました。そのBOD 22-01は、執筆時点で2026年6月10日発行のBOD 26-04（Prioritizing Security Updates Based on Risk）に置き換えられ、廃止されています。ただしKEVカタログ自体は引き続き維持・運用されており、登録基準も変わっていません。

このBOD 26-04が、本記事のテーマそのものを象徴しています。CISAは連邦の優先度付けの必須入力としてのCVSSを取りやめ、後述するSSVCの考え方に基づくリスクベースの判断へ移行しました。判断は、資産がインターネットに公開されているか、KEVに載っているか、悪用を全自動化できるか、技術的影響はどうか、という観点で行います。これらの組み合わせに応じて対応期限が段階的に決まり、最も高リスクの組み合わせ（公開資産・KEV該当・全自動化可・完全な制御）では最短3日での修正と、すでに悪用されていないかを確かめるフォレンジック・トリアージまで求める、という設計です。深刻度の数値を絶対視せず、実際の悪用と環境を重ねて優先度を決める、という流れが、公的な方針としても明確になったわけです。

CISAのBOD 26-04（Prioritizing Security Updates Based on Risk）は、執筆時点の公表で2026年6月10日に発行され、BOD 22-01およびBOD 19-02を置き換えました。連邦民間機関の優先度付けでCVSSを必須入力とせず、資産の公開状況・KEV該当・悪用の自動化可否・技術的影響といったリスク要素に基づく判断へ移行しています（執筆時点の記載に基づく）。

SSVC: 数値ではなく「意思決定」を構造化する#

SSVC（Stakeholder-Specific Vulnerability Categorization）は、対応の意思決定を木構造（決定木）で整理する手法です。カーネギーメロン大学のソフトウェア工学研究所（CMU SEI）がCISAと協力して2019年に考案しました。数値スコアを付けるのではなく、いくつかの判断ポイント（悪用状況・技術的影響・自動化可能性・自組織での重要度など）を順にたどって、行動カテゴリを導きます。

CISAが運用する決定木では、最終的に次の4つのいずれかに振り分けられます。

SSVCの利点は、スコアの大小に頼らず、「自組織の立場から見てどう動くべきか」を明文化できることです。CVSS・EPSS・KEVが「指標」だとすれば、SSVCはそれらの指標を入力として「行動」を決めるための枠組みだと捉えると、役割の違いが整理できます。前述のBOD 26-04も、このSSVCの考え方を土台にしています。

3つを組み合わせた優先度マトリクス#

ここまでの指標を、実務で使える優先度マトリクスに落とし込みます。考え方の軸は、(1)KEV該当を最優先の即時対応に引き上げる、(2)残りをCVSS（深刻度）とEPSS（悪用確率）で振り分ける、という二段構えです。次の表は運用の出発点となるテンプレートで、しきい値や期限は自社の体制・リスク許容度に合わせて必ず調整してください。

このマトリクスの肝は、KEV該当を他の数値より上に置くことと、「高CVSSだが低EPSS」を機械的に最優先扱いしないことです。深刻度が高くても悪用確率が極端に低く、対象資産が隔離環境にあるなら、緊急度は相対的に下がります。逆に、CVSSが中程度でもEPSSが高く、その資産がインターネットに公開されているなら、前倒しの判断が妥当です。

EPSSはあくまで悪用「確率」であり、自社環境の重要度までは織り込みません。最終的には、その資産がどれだけ重要か、公開範囲はどうか、既存の緩和策があるか、という環境の文脈を重ねて補正します。この補正の考え方は、CVSSの環境評価やSSVCの観点と地続きです。

実務での運用ステップ#

優先度マトリクスを、日々の運用フローに組み込む手順に落とすと次のようになります。

このフローは、依存ライブラリの脆弱性管理（SCA）とも噛み合います。ソフトウェアコンポーネントから検出された大量の脆弱性も、同じくKEVとEPSSで層別すれば、対応すべきものを現実的な数に絞れます。依存関係の脆弱性管理については

ありがちな誤解と判断のコツ#

実務でつまずきやすい誤解を整理します。

第一に、「Critical（CVSS 9.0以上）は常に最優先」という思い込みです。深刻度が高くても、悪用が観測されておらず（KEV非該当・低EPSS）、対象資産が隔離環境にあり、すでに緩和策が入っているなら、緊急度は下がります。深刻度（severity）と緊急度（urgency）は別物です。

第二に、「EPSSが低いから対応しなくてよい」という早合点です。EPSSは予測であり、ゼロデイのように予測が追いつかない悪用もあります。とくに公開資産や重要資産では、EPSSが低くてもCVSSや影響を見て判断すべき場面があります。新規の悪用がいつ出るか分からない脆弱性の扱いについては

第三に、「KEVに載っていなければ安全」という誤解です。前述のとおり、KEVは悪用が確認・公表されたものの一覧であって、まだ観測されていない悪用は載りません。KEV非該当を安全の根拠にしないでください。

これらに共通するのは、単一の指標を絶対視せず、深刻度・悪用確率・悪用実績・自社の文脈を重ねて判断する姿勢です。指標は判断を助ける材料であって、判断そのものを肩代わりするものではありません。CISAが連邦方針でCVSS必須をやめ、複数のリスク要素による判断へ移行したのも、まさにこの発想の延長線上にあります。

よくある質問#

まとめ#

毎月大量に出るパッチを全部当てるのは不可能だ、という前提に立つことが、現実的な脆弱性管理の出発点です。深刻度（CVSS）は理論上の最悪を、悪用確率（EPSS）は今後30日の見通しを、悪用実績（KEV）は現実に攻撃された事実を表します。この3つを組み合わせ、KEV該当を即時、高CVSS×高EPSSを前倒し、と層別すれば、限られた人手を本当に危ないものへ集中できます。米CISAが連邦方針でCVSS必須をやめ、KEVや悪用の自動化可否を軸にしたリスク判断へ移行したことも、この方向性を後押ししています。数値は判断を助ける材料であって、判断そのものではない。複数の指標と自社の文脈を重ねて優先度を決める姿勢が、実務では最も効きます。