脆弱性対応の優先順位はどう決める？CVSS・EPSS・KEVを使った判断方法を解説

はじめに

ツールによる脆弱性スキャンを始めると、脆弱性が数百件見つかることがあります。 すべてを直ちに修正するのは不可能なので、どれから着手するかを決めなければなりません。 CVSSの値が高い脆弱性から順に対応していくのが合理的に見えるかもしれません。

しかし、CVSSの基本値が示すのは脆弱性の技術的な深刻度であり、自社が攻撃を受ける確率や事業への影響を含む完全なリスクではありません。 外部に公開され、すでに悪用されている脆弱性が、より高いCVSSの脆弱性より後回しになることもあります。 このずれを補うのが、悪用の起こりやすさを推定するEPSSと、悪用実績を示すKEVです。

脆弱性対応の優先順位は、CVSS、EPSS、KEVのどれか1つで決めるものではありません。 3つの指標に、対象資産の露出状況、事業上の重要度、緩和策の有無を重ねて判断します。

脆弱性評価に便利な3つの指標

CVSS、EPSS、KEVは競合する評価方法ではなく、脆弱性を異なる面から評価するための指標です。 CVSSは「悪用された場合に技術的にどれほど深刻か」、EPSSは「今後30日間に悪用が観測される可能性はどの程度か」、KEVは「すでに実環境で悪用された証拠があるか」を表します。

この違いを押さえると、CVSSが高いという理由だけで全件を緊急扱いする運用を避けられます。 反対に、CVSSがCriticalではない脆弱性でも、KEVに掲載され、自社の外部公開資産に該当するなら対応を急ぐ理由が成立します。

CVSSは技術的な深刻度を比較する

CVSSは、脆弱性の特性と深刻度を共通の基準で表す仕組みです。 CVSS v4.0の基本評価では、攻撃経路、攻撃の複雑さ、必要な権限、利用者の操作、機密性、完全性、可用性への影響などを評価し、0.0から10.0の値で示します。 異なる製品の脆弱性を同じ軸で比較できることが強みです。

公開情報でよく見かけるCVSS基本値は、脆弱性そのものの性質を合理的な最悪条件で評価したものです。 FIRSTも、基本値は深刻度を測るものであり、単独でリスクを測るものではないと説明しています。 評価時は点数だけでなく、CVSSのバージョンと、算出根拠を表すベクター文字列も確認します。

自社で優先順位を判断する際は、「外部から到達できない」「対象機能を無効化している」「可用性が特に重視される業務で使っている」といった環境情報を加味します。 CVSS v4.0ではThreat MetricsとEnvironmental Metricsを使って、悪用状況や自社環境を反映した評価も可能です。 ただし、顧客への影響や法令上の要求など、CVSSの範囲外にある事業情報は別に判断しなければなりません。

EPSSは近い将来の悪用確率を推定する

EPSSは、公開されたCVEが今後30日間に実環境で悪用される確率を、機械学習モデルで推定する指標です。 0から1の値で毎日更新され、0.05なら同程度のスコアを持つ脆弱性群の約5％で、30日以内に悪用が観測されるという意味になります。

EPSSには確率とパーセンタイルがあります。 確率は悪用が観測される見込みを示し、パーセンタイルは他のCVEと比べた相対的な順位を示します。 分布が低い値へ偏るため、しきい値を決める際は確率だけでなくパーセンタイルも併記すると、対応対象が全体のどの範囲に当たるかを把握しやすくなります。

ただし、EPSSは自社の資産構成や緩和策、悪用された場合の被害を知りません。 高いEPSSは対応を急ぐ強い材料になりますが、「EPSSが低ければ安全」を意味するものではありません。 スコアは日々変わるため、検出時の値を固定したままにせず、未対応項目を定期的に再評価します。

KEVは確認済みの悪用実績を示す

KEV（Known Exploited Vulnerabilities Catalog）は、米国CISAが管理する、実環境での悪用が確認された脆弱性のリストです。 KEVの掲載は将来の予測ではなく、活動中の攻撃者がその脆弱性を使った証拠があることを示します。 カタログには追加日、要求される対応、対応期限などが収録されています。

CISAの対応期限が法的に直接適用されるのは、米国の連邦文民行政機関です。 ただしCISAは、ほかの組織にもKEV掲載項目の迅速な修正を推奨しています。 民間企業でも、自社に該当するKEVを緊急トリアージへ送る運用は、限られた要員を悪用実績のある脆弱性へ集中させる方法になります。

とはいえ、KEVに掲載されているCVEが自社の利用製品に該当したとしても、すべてが同じ優先度になるわけではありません。 影響を受けるバージョンか、該当機能を使っているか、攻撃者が到達できるかを確認し、外部公開された重要資産から対応します。

優先順位を決める5つの手順

1. 自社資産への該当を確認する

最初に、検出したCVEが実際に自社資産へ影響するかを確認します。 製品名だけで判断せず、バージョン、設定、利用中の機能、ベンダーのアドバイザリ、スキャナの検出根拠を照合します。 対象外の項目を先に除かなければ、どれほど精密な優先順位を付けても修正能力を浪費します。

資産台帳には、所有者、外部公開の有無、保存する情報、支える業務、停止時の影響を紐づけます。 脆弱性情報と資産情報を結び付けることで、同じCVEでも本番環境と隔離された検証環境を分けて判断できます。

2. KEV掲載の有無を確認する

該当が確認できた脆弱性は、KEVとの照合を先に行います。 KEV掲載済みで、インターネットから到達できる機器や認証基盤などに影響する場合は、通常の月次対応を待たず、緊急の調査対象にします。

パッチをすぐに適用できない場合でも、外部公開の停止、アクセス元の制限、脆弱な機能の無効化、侵害痕跡の調査を検討します。 緩和策は恒久対応と区別し、適用範囲、判断者、有効期限を記録します。

3. EPSSで悪用の切迫度を比較する

KEVに未掲載の脆弱性は、EPSSの確率とパーセンタイルを使って、近い将来に悪用されやすい項目を絞ります。 とくに外部公開資産でEPSSが上昇している場合は、KEVへの掲載を待たずに修正を前倒しする判断ができます。

EPSSに普遍的な合格点はありません。 たとえば上位10％を調査対象にする方法や、確率と資産の露出を組み合わせる方法が考えられますが、選んだ基準で月に何件の対応が発生するかを試算し、実行可能な値へ調整します。

4. CVSSと事業影響で被害の大きさを評価する

次にCVSSの点数とベクターを確認し、攻撃に必要な条件と、悪用時に起こり得る技術的な影響を把握します。 その上で、管理者権限や機密情報へ到達できるか、業務停止が顧客へ波及するか、代替手段があるかを評価します。

CVSSが同じでも、個人情報を扱う本番システムと、合成データだけを置いた検証環境では被害が異なります。 技術的な深刻度を事業上の重要度へ読み替える工程は、公開スコアだけでは自動化できません。

5. 対応区分と期限を決める

最後に、評価結果を「緊急対応」「優先対応」「計画対応」「リスク受容」などの区分へ落とし込み、担当者と期限を決めます。 区分には判断条件と標準期限を設定しますが、修正による停止リスクや代替策も踏まえ、例外を承認する手順を用意します。

表の期限はあくまで設計例です。 自社の人員、変更管理、システムの停止可能時間に合わせて期限を定め、守れない基準を掲げるより、例外が可視化される運用にします。

CVSSが低くても対応を優先すべきケース

たとえば、CVSS 9.8の脆弱性Aが隔離された検証環境にだけ存在し、EPSSが低く、KEVにも未掲載だったとします。 対して、CVSS 8.1の脆弱性BはKEVに掲載され、インターネットへ公開した本番機器に存在し、認証なしで悪用できる状態です。 この条件なら、先に対応すべきなのは脆弱性Bです。

このような優先順位の逆転は、決してCVSSを軽視した結果ではありません。 脆弱性Bには悪用実績と現実の到達経路があり、被害が起きる条件がすでにそろっているからです。 脆弱性Aも放置せず計画対応へ残し、EPSSの上昇、KEVへの追加、環境変更があれば優先度を引き上げます。

優先順位を更新し続ける運用

優先順位は、検出時にだけ決めるものではありません。 EPSSは毎日更新され、KEVには新しいCVEが追加されます。 資産側でも外部公開、設定、保存データ、業務上の役割が変わるため、未対応の脆弱性は継続的な再評価が必要です。

日次処理では、スキャナの結果にEPSSとKEVの情報を付与し、新規掲載やスコア上昇を検出します。 週次または月次のレビューでは、期限超過、例外の有効期限、資産所有者が不明な項目を確認します。 判断記録には、参照した指標の値と取得日、資産の状態、優先度を決めた理由を残します。

運用指標としては、脆弱性の総数だけでなく、KEV掲載項目の未対応数、優先度別の期限内対応率、検出から初動判断までの時間を追います。 総数はスキャン範囲を広げただけでも増えるため、リスク低減の進み具合を単独では表せません。

まとめ

CVSSは技術的な深刻度、EPSSは今後30日間に悪用が観測される確率、KEVは確認済みの悪用実績を示します。 3つは置き換えられる指標ではなく、異なる情報を補い合う関係です。

実務では、まず自社資産への該当を確かめ、KEV掲載項目を緊急トリアージへ送ります。 未掲載の項目はEPSSで悪用の切迫度を比較し、CVSSと資産の露出状況、事業への影響を重ねて、担当者と期限を決めます。 判断を定期的に更新する仕組みまで整えて初めて、優先順位が日々のリスク変化に追随します。

脆弱性管理の体制づくりにお困りの場合

自社だけで評価基準の設計や対応状況の管理を続けることが難しい場合は、弊社のセキュリティチーム代行サービスをご検討ください。 資産と役割の整理、優先順位付けのルール作成、脆弱性のトリアージ、対応状況のレビューまで、外部のセキュリティチームとして支援します。