実務ガイド

悪用されているかを判断する方法
(KEV/EPSS/PoCでCVE優先度を即決する)

CVE対応で一番つらいのは、技術的な難しさよりも 「結局これ、いま対応すべき?」 が毎回ぶれることです。

  • “深刻度が高い”と言われても、実害があるか分からない
  • OEM照会は期限(SLA)があるのに、判断材料が散らばっている
  • 「影響なし」の根拠が弱く、追加質問が止まらない
  • 優先度が決まらず、現場が疲弊する

ここで便利なのが、「実際に悪用されているか」を示す“シグナル(信号)”です。
代表的なものが KEV / EPSS / PoC の3つ。これを使うと、トリアージが“属人的な判断”から“運用”に変わります。

先に結論:悪用判断は「3つの信号」で8割決まる

悪用有無を“断定”するのは難しいですが、実務では 「悪用されやすい(または既に悪用されている)可能性」 を根拠付きで示せれば十分です。
見るべき信号はこの3つだけです。

KEV

Known Exploited Vulnerabilities:既知の悪用が確認されたCVEか?

EPSS

Exploit Prediction Scoring System:今後(近い期間)悪用される確率が高いか?

PoC

Proof of Concept:公開PoCが出て“再現コスト”が下がっているか?

重要:この3つは「優先度を上げる材料」です。
“自社が影響を受けるか(SBOM/到達性)”の確認とセットで使うのが鉄則です。

KEV:一番強い“既知悪用”シグナル(最優先で見る)

CISA(米国サイバーセキュリティ・社会基盤安全保障庁)が公開しているKEVカタログに載っているということは、「現実に悪用されている」という最も強い優先度根拠になります。

運用ルールはシンプルです。

  • KEV掲載:Yes → 原則 P0(即対応候補)
    ※ただし「自社が影響を受ける(搭載+到達性)」の確認は外さない。非搭載なら不要です。
  • KEV掲載:No → 次にEPSS/PoCへ(“今後悪用される確率”の評価へ移行)
📝 OEM向けの書き方(例)

「当該CVEは KEV未収載(確認日:YYYY-MM-DD)。現時点で既知悪用の確証は確認できていません。」

※「悪用されていない」と断定しないのがコツです(“未確認”が安全)。

EPSS:悪用“確率”の指標(閾値は「絶対値」より「相対」で決める)

EPSSは「今後30日以内に悪用される確率」の予測指標で、“次に燃えそうなCVE” を拾うのに強いです。

ただし、スコアは日々変動するため、運用では 絶対値よりも相対順位(上位◯%) で扱う方がブレません。

おすすめのルール例(まずはこれで十分):
  • EPSS 上位1%(または上位5%) → 優先度を上げる
  • EPSS 低位 → 他の条件(PoC・到達性・期限)次第で後回しにできる
📝 “実務の言い回し”の型(例)

「EPSSは 上位◯%(確認日:YYYY-MM-DD)。悪用確率が相対的に高いため、優先度を上げて評価します。」

EPSSは「優先順位の補助」です。EPSSが高くても、自社が非搭載ならノイズです。逆にEPSSが低くても、KEV掲載やOEM期限があれば最優先になります。

PoC:再現コストが下がった“拡散シグナル”(過信しない)

PoC(Proof of Concept:概念実証コード)が公開されると、攻撃の再現コストが下がり、悪用が広がりやすくなります。

ただし注意点もあります。

  • PoCがある=悪用中 ではない(研究目的のPoCも多い)
  • PoCがない=安全 でもない(非公開で悪用されることもある)

運用上の扱いはこう割り切るのが安全です。

PoCあり
優先度を“1段階上げる材料”にする
PoCなし
優先度を下げる根拠にはしない(他要素次第)
🛡️ 証跡として残すべき情報(最低限)
  • PoC確認の有無(Yes/No/不明)
  • 確認日
  • 根拠(参照先・内部メモID)

※PoCそのものの詳細(手順/コード)は、社内規程上も外部提出上も不要なことが多いです。

3信号を“判定ロジック”に落とす(迷わない最小ルール)

ここからが「やり方」です。KEV/EPSS/PoCは、以下の3段階に分類して運用すると安定します。

A:Hot(最優先)

条件:

  • KEV掲載 = Yes
  • または、EPSS上位 かつ PoCあり(拡散兆候が強い)

→ まず 一次回答(受領+次回更新日) を返し、暫定対策/恒久対策の検討へ。

B:Warm(優先評価)

条件:

  • KEV未収載だが、EPSSが相対的に高い
  • または、PoCあり で、到達性があり得る

→ 対象版数と到達性を切り、影響判定(VEX)へ。

C:Cold(定例/監視)

条件:

  • KEV未収載、EPSS低位、PoC確認なし(または不明だが期限なし)

→ バックログに落として監視(情報更新でWarmへ昇格)。

【コピペ用】悪用シグナル判定メモ(チケット/台帳に貼る)

CVE:CVE-____ 確認日:YYYY-MM-DD KEV:Yes / No / 不明(根拠:____) EPSS:スコア____/上位◯%(根拠:____) PoC:あり / なし / 不明(根拠:____) 悪用シグナル判定:Hot / Warm / Cold 次回更新日:YYYY-MM-DD 証跡リンク/ID:____

トリアージの判定基準を「上手く回る」形に整理したい方はご相談ください。

【無料】オンライン相談を予約する

よくある落とし穴(これだけ避けると運用が軽くなる)

  • CVSSだけで優先度を決める: 悪用中/拡散兆候が反映されず、優先度がズレる
  • 「悪用されていない」を断定する: 未確認の情報で言い切ると、後で覆って炎上する
  • 確認日が残っていない: EPSSなどは変動するため、時点情報が無いと監査で弱い
  • PoCの存在だけでP0にする: 到達性/搭載がNoならノイズ処理が増える
  • 次回更新日がない: 調査中の案件が“放置”に見える(SLA運用が崩れる)

FAQ:悪用シグナルの判断について

Q1. 「悪用されているか」を100%正確に判断できますか?

難しいです。実務では「KEV掲載」「EPSSの相対順位」「PoCの有無」という“悪用シグナル”を根拠に、優先度と次アクションを決めるのが現実解です。

Q2. KEVに載っていたら必ず緊急対応ですか?

原則は優先度が大きく上がります。ただし、最終的には「自社が影響を受けるか(搭載・到達性)」の確認が必要です。KEV=無条件に全社対応、にするとノイズが増えます。

Q3. EPSSは何点以上なら危険ですか?

スコアは変動するため、運用では「上位◯%」など相対で扱う方がブレません。まずは上位1%/5%を優先評価のトリガーにすると回しやすいです。

Q4. PoCが公開されているとき、OEMにどう説明しますか?

PoCの詳細は不要なことが多いです。「PoC公開により再現コストが下がる可能性」を示しつつ、搭載・到達性・対象版数・暫定対策/恒久対策・次回更新日をセットで返すと追加質問が減ります。

KEVやEPSSのチェック、毎日手動でやっていませんか?

Auto PSIRT Cloudなら、最新のKEVリストやEPSSスコアを自動で取得・評価し、自社のSBOMと照らし合わせて「Hot / Warm / Cold」のトリアージをAIが即座に提案します。