メインコンテンツへスキップ
Securify

EPSSとは?確率・パーセンタイルの読み方と脆弱性対応への使い方

セキュリティ解説Securify編集部読了目安 約 10 分
目次27項目
EPSSとは?確率・パーセンタイルの読み方と脆弱性対応への使い方

はじめに

EPSS(Exploit Prediction Scoring System)は、公開済みのCVEについて、今後30日間に実際の攻撃で悪用される(悪用の試みが観測される)確率を推定するモデルです。FIRSTが、CVEごとの確率(スコア)とパーセンタイルを日次で公開しています。自社が攻撃を受ける確率や、侵害に成功される確率を直接表したものではありません。出典:FIRST EPSS

本記事では、EPSSの確率とパーセンタイルの読み方、CVSS・KEVとの違い、脆弱性対応の優先順位付けに使う方法と注意点を解説します。


EPSSとは?なぜ必要か?

CVEとして公開される脆弱性は膨大な数にのぼり、すべてに同じ優先度で対応することは現実的ではありません。

従来、多くの組織はCVSS(共通脆弱性評価システム)を基準に対応の優先順位を決めてきました。しかし、CVSS 7.0(High)以上をすべて対象にすると、対応件数は大きくなりがちです。CVSSの基本評価は脆弱性の技術的な深刻度を示すもので、実際の攻撃で使われているかどうかを直接表すものではありません。

一方で、公開された脆弱性のうち、実際の攻撃で悪用が観測されるのは一部にとどまります。

つまり、CVSSの深刻度だけで対応範囲を決めると、悪用される可能性が低い脆弱性にも多くの工数を割くことになりかねません。限られたリソースを悪用の可能性が高い脆弱性へ向けるために、「悪用の可能性」を推定するEPSSが使われています。


EPSSの基本概念

EPSSとは

  • EPSS(Exploit Prediction Scoring System)は、FIRSTが開発・公開している、脆弱性の悪用可能性を推定する指標です。

公開済みのCVEについて、「今後30日間に実際の攻撃で悪用が観測される確率」を0〜1の値で推定する

スコアが高いほど、近い将来に悪用が観測される可能性が高いとモデルが推定していることを示します。

CVSSとの決定的な違い

指標

評価内容

性質

CVSS

脆弱性の技術的な深刻度(影響度)。バージョンと評価ベクトルも確認する

比較的静的(基本評価は脆弱性の特性に基づく)

EPSS

今後30日間に悪用が観測される確率の推定

動的(日次で更新)

CVSSが9.0(Critical)でも、攻撃コードが出回っておらず悪用の兆候が少なければ、EPSSは低い値にとどまることがあります。逆に、CVSSが5.0(Medium)程度でも、攻撃コードが容易に入手できる場合などは、EPSSが高くなることがあります。どちらかが正しいということではなく、CVSSは「悪用された場合の影響の大きさ」、EPSSは「悪用の可能性」という別の観点を示しています。

スコアの仕組み

EPSSは、脆弱性に関する公開情報と、実際に観測された悪用活動のデータを用いた機械学習モデルでスコアを算出します。モデルの詳細はFIRSTのモデル解説で公開されています。

モデルが考慮する情報の例:

  • CVSSの評価(攻撃元区分など)
  • 攻撃コード(PoC)の公開状況(GitHub、Exploit-DBなど)
  • 脆弱性の種類(CWE)
  • ベンダー勧告、NVDなどの参照情報

スコアは毎日更新されます。攻撃コードの公開などをきっかけに、スコアが急に上がることもあります。

提供される値:確率とパーセンタイル

FIRSTは、CVEごとに次の2つの値を公開しています。名前は似ていますが、意味はまったく異なります。

  1. EPSSスコア(Probability/確率):そのCVEについて、今後30日間に悪用が観測される確率の推定値です。0〜1で表し、たとえば0.2なら、モデルが推定した悪用確率は20%です。
  2. パーセンタイル(Percentile):スコアが付いた全CVEの中での相対的な順位です。たとえば0.98(98パーセンタイル)なら、全CVEのうち98%がそのCVEと同じかそれより低いスコアであり、上位およそ2%に入ることを示します。

パーセンタイルは確率ではありません。90パーセンタイルを「悪用確率90%」と読むことはできず、確率とパーセンタイルの数値は一般に一致しません。しきい値を決めたり報告したりする際は、どちらの値を使っているのかを明記します。解釈の注意点はFIRSTのFAQに整理されています。


EPSSの効果

対応範囲と効率のトレードオフ

どの基準で対応対象を選ぶかは、次の3つの観点で比べると違いが分かりやすくなります(FIRSTのモデル解説も、この3つの観点で評価を示しています)。

観点

意味

工数(Effort)

対応対象として選んだ脆弱性が、全体に占める割合

カバレッジ(Coverage)

実際に悪用された脆弱性のうち、対応対象に含まれていた割合

効率(Efficiency)

対応対象として選んだ脆弱性のうち、実際に悪用された割合

FIRSTのモデル解説では、2023年10月1日時点でCVSS v3.xのスコアが付いていたCVE(約14万件)を対象に、その後30日間に悪用活動が観測されたCVEと照らし合わせて、2つの基準を比べています。

対応基準

工数

カバレッジ

効率

CVSS 7.0以上

57.4%

82.2%

3.96%

EPSS 0.1以上

2.7%

63.2%

65.2%

この例では、EPSS 0.1以上に絞ると、CVSS 7.0以上を対象にする場合より工数が大幅に小さく、効率も高くなっています。その一方で、カバレッジはCVSS 7.0以上の場合より低くなっています。

一般に、CVSSの高いものから幅広く対応すると、カバレッジは高くなりやすい一方で、工数が大きくなり効率は下がります。EPSSのしきい値で対象を絞ると効率を上げやすくなりますが、しきい値を高くするほど、悪用される脆弱性の一部が対象から漏れる(カバレッジが下がる)可能性があります。どの程度の効果が出るかは、しきい値、対象とする脆弱性、時期によって変わります。

意思決定の迅速化

CVSSの深刻度に加えて、「悪用の可能性」という別の観点を数値で示せるため、対応を急ぐ理由や後回しにする理由を説明しやすくなります。経営層には「このCVEは、今後30日間に悪用が観測される確率が○%と推定されている(○月○日時点)」のように伝えます。「○%の確率で自社が攻撃される」という説明は誤りなので、自社での利用状況や外部公開の有無とあわせて説明します。

KEVとの関係

CISAのKEV(Known Exploited Vulnerabilities)カタログは、実際の悪用が確認された脆弱性の一覧です。EPSSが「これから悪用が観測される可能性」の推定であるのに対し、KEVは「悪用が確認された」という事実を示します。EPSSの高い脆弱性を優先しても、それだけでインシデントを防げるわけではありません。KEVに掲載された脆弱性や、自社で侵害の兆候がある脆弱性は、EPSSの値が低くても後回しにできません。


具体的な活用方法

まず資産台帳やSBOMから、自社で使っている製品・バージョンに影響するCVEを集めます。スコアが高くても、影響を受ける製品・バージョンを使っていなければ、そのCVEの修正は対象になりません。そのうえで、外部公開された重要システムや悪用確認済みの問題を優先して確認し、残る問題の調査順を決める材料にEPSSを使います。

活用1:パッチ適用の優先順位付け

閾値の設定例:

次の表は考え方を示すための例です。表中のEPSSの値は確率(スコア)で、パーセンタイルではありません。しきい値や期限は、対応できる件数や対象システムの重要度に合わせて自社で検証します。「0.1以上なら全社一律に緊急」といった基準を、根拠なしに採用することは避けます。KEV掲載の扱いは後述の運用ルールを参照してください。

優先度

条件

対応SLA

緊急

EPSS > 0.9 AND CVSS > 7.0

72時間以内

高

EPSS > 0.5

14日以内

中

EPSS > 0.1 OR CVSS > 9.0

30日以内

低

上記以外

90日以内

活用2:CVSSとEPSSの併用マトリクス

EPSS 高

EPSS 中

EPSS 低

CVSS 高

最優先(即時対応)

優先(計画的対応)

監視(影響大だが悪用可能性低)

CVSS 中

優先(隠れた脅威)

計画的対応

後回し

CVSS 低

監視強化

後回し

後回し

  • 「CVSS 中/低 × EPSS 高」は、CVSSだけで判断すると見逃されやすい脆弱性です。

考え方の例:CVSSでは中程度(Medium)の評価でも、攻撃コードの公開などをきっかけにEPSSが高くなる脆弱性があります。このような脆弱性は、CVSSだけで判断すると「後回し」に分類されかねません。なお、記事や資料に載っている過去のEPSSの値ではなく、確認時点の値で判断します(後述の「スコアの変動性」を参照)。

活用3:セキュリティツールとの統合

  • 脆弱性管理(VM)ツール:EPSSを表示したり、絞り込みの条件に使えたりする製品もあります。表示されているのが確率かパーセンタイルかを確認しておきます。
  • SIEM/SOAR:「EPSSスコアが0.9を超えたら自動でチケットを発行する」といったワークフローを組むこともできます。

活用4:ポリシー・SLAへの組み込み

  • リスクベースSLA:「CVSS 9.0以上はすべて24時間以内」のようにCVSSだけで期限を決めるのではなく、KEV掲載の有無、EPSS、資産の重要度や外部公開の有無を組み合わせて期限を定義します。CVSSをEPSSに置き換えるだけでは、悪用は観測されていないものの影響の大きい脆弱性を見落とすおそれがあります。
  • リスク受容基準:「EPSS 0.01未満かつCVSS 4.0未満は当面の対応を見送る」といった基準を設ける場合は、EPSSが日々変わることを前提に、見送りの理由と再確認日を記録しておきます。

他の指標との比較と併用

主要指標の比較

指標

提供元

評価内容

更新頻度

メリット

デメリット

CVSS

FIRST

技術的な深刻度

基本評価は変わりにくい

標準化された評価軸

基本評価は悪用状況を反映しない

EPSS

FIRST

今後30日間に悪用が観測される確率

日次

対応を絞り込める

算出根拠を直感的に説明しにくい

KEV

CISA

悪用が確認された事実

随時

悪用の証拠に基づく

確認後の掲載のため後追いになる

SSVC

CERT/CC・CISA

対応方針の決定

状況の変化に応じて再評価

自社の状況を考慮できる

判断基準の設計・運用が必要

推奨する併用アプローチ

リスクは一般に「起こりやすさ」と「影響の大きさ」の両面から考えます。CVSSは主に影響の大きさ(深刻度)、EPSSは悪用の起こりやすさに関わる情報です。

ただし、CVSSとEPSSを単純に掛け合わせても、意味の明確なリスク確率にはなりません。CVSSは0〜10の深刻度の尺度、EPSSは0〜1の確率で、性質の異なる値です。掛け合わせた数値を「リスクの大きさ」として扱わず、両者を別々の軸として並べ、前述のマトリクスのように組み合わせて使います。参考:FIRST Using EPSS

CVSSだけでは「悪用の可能性」が、EPSSだけでは「悪用された場合の影響」が見えません。両方に加えて、KEVと自社の資産情報(対象製品の利用、外部公開、業務の重要度、対策状況)を組み合わせます。

運用ルールの例:

  1. 影響を受ける製品・バージョンを使っているか確認
  2. KEV掲載 → 最優先(EPSSの値に関わらず対応)
  3. KEV未掲載 × EPSS高 → 優先対応
  4. EPSS + CVSSマトリクスで分類し、外部公開の有無や業務の重要度で調整

EPSSの限界と注意点

説明可能性の制約

機械学習モデルのため、「なぜこのスコアなのか」を個々のCVEについて直感的に説明しにくい面があります。

データソースの偏り

EPSSは、公開情報や観測された悪用活動のデータに基づいて推定します。そのため、公開情報や観測データが少ない製品の脆弱性では、実際の脅威が値に反映されにくい可能性があります。主に国内で使われている製品などは、EPSSだけで判断せず、ベンダーの注意喚起など他の情報もあわせて確認します。

NVD登録のタイムラグ

2024年以降、NVDでは処理の遅延が発生しており、CVE公開から詳細情報の付与までに時間がかかるケースがあります。公開直後の脆弱性には、EPSSスコアがまだ付与されていないことがあります。

スコアの変動性

前述のとおりスコアは日次で更新されるため、一度確認した値を使い続けるのではなく、継続的なモニタリングや、スコアの急上昇を検知する仕組みを用意しておきます。攻撃動向やモデルの更新によって値が変わるため、異なる日の数値をそのまま比較すると判断を誤ることがあります。判断に使った値は、取得日とともに記録しておきます。

予測の限界

EPSSは予測モデルであり、偽陽性(高スコアだが悪用されない)・偽陰性(低スコアだが悪用される)は発生します。

FIRSTの公式見解:「実際に悪用されている証拠がある場合、その情報はEPSSの予測よりも優先されるべきです。」


まとめ

EPSSは、膨大な脆弱性の中から「今後30日間に悪用が観測される可能性が高いもの」を推定し、限られたリソースの配分を検討するための指標です。CVSSが示す「深刻度」に、EPSSが示す「悪用の可能性」、KEVが示す「悪用確認の事実」、そして自社の資産情報を組み合わせることで、根拠を説明できる優先順位付けがしやすくなります。運用では、確率とパーセンタイルを取り違えないこと、取得日を記録すること、しきい値を自社で検証することがポイントです。

まとめの説明画像

スコアだけを集めても、担当者や修正対象が分からなければ対応は進みません。Securify SBOMは、リポジトリ・コンテナ・クラウドからソフトウェア構成を収集し、利用中のコンポーネントとバージョンを脆弱性情報と照合します。ASM・CSPMとの連携で、その部品を使う稼働資産も把握できます。公開資産の把握にはSecurify ASMをご覧ください。

脆弱性対応の優先順位付けや、資産・ソフトウェア構成の管理についてご関心があれば、お気軽にお問い合わせください。

まとめの説明画像

参考文献

Get Started

WebサイトやAPIの脆弱性を継続診断し、修正後の確認にも活用できます。

ご利用規模・診断頻度に合わせて最適なプランをご提案します。

WebサイトやAPIの脆弱性を継続診断し、修正後の確認にも活用できます。