KEVとは ─ CVE対応の優先順位を決める実務

KEVは「悪用済み」の合図として読む

新しいCVEが公開されるたびに、CVSS 9.8やCriticalという言葉だけで緊急対応を決めていると、現場はすぐに疲弊する。深刻度が高い脆弱性は多い。一方で、実際に攻撃で使われているもの、自社の外部公開資産に刺さるもの、業務停止に直結するものは限られる。

そこで確認したいのが KEV（Known Exploited Vulnerabilities） だ。CISAのKEVカタログは、実際に悪用が確認された脆弱性を整理した一覧であり、脆弱性管理の優先順位を決めるための強いシグナルになる。

ただし、KEVに入っているから必ず全社最優先、KEVに入っていないから安全、という読み方は危険だ。実務では、KEV、CVSS、EPSS、外部露出、自社資産の重要度を合わせて、対応順を決める必要がある。

この記事の前提

KEVは「悪用済みかどうか」を見る材料であり、単独のリスク判定ではない。
CVSSは不要にならない。技術的な深刻度を把握するために引き続き使う。
ここで扱うのは防御・運用判断のための整理であり、攻撃手順や悪用コードは扱わない。

CVSSだけで優先順位を決めると何が抜けるか

CVSSは便利だ。攻撃元区分、攻撃条件、必要権限、ユーザー操作、機密性・完全性・可用性への影響を、共通の尺度で表現できる。CVEを初めて見る担当者でも、危険度の目安をつかみやすい。

しかし、CVSSだけでは次の情報が抜け落ちる。

CVSSだけでは分からないこと	実務上の影響
実際に悪用されているか	攻撃が始まっている脆弱性を後回しにする可能性がある
自社に対象製品があるか	存在しない資産に時間を使い、重要資産の確認が遅れる
インターネットから到達できるか	外部公開資産と社内限定資産を同じ優先度で扱ってしまう
認証情報や管理権限に近いか	侵害後の横展開や資格情報流出の影響を見落とす
暫定対策が可能か	パッチ待ちのあいだに露出遮断やWAFで下げられるリスクを放置する

たとえば、CVSSがCriticalでも自社に対象製品がないなら、緊急パッチ作業は不要だ。一方で、CVSSがHighでも、KEV入りし、外部公開の管理画面に該当し、過去に認証情報流出へつながった製品なら、最優先で扱うべき場合がある。

詳しい違いは CVEとCVSSの違いでも整理している。CVEは識別子、CVSSは深刻度、KEVは悪用状況のシグナルとして分けて読むと、判断がぶれにくい。

優先順位は5つの軸で見る

脆弱性対応の初動では、次の5つを同じ表で見るとよい。

軸	確認すること	判断に使う意味
KEV	CISA KEVに掲載されているか	既に悪用が確認された脆弱性として優先度を上げる
CVSS	スコアとベクター	技術的な深刻度、必要権限、ユーザー操作の有無を見る
EPSS	悪用確率とパーセンタイル	今後悪用される可能性の参考値として使う
露出	インターネット公開、VPN内、社内限定、検証環境	攻撃者が到達できるかを判断する
資産重要度	認証基盤、管理画面、顧客データ、開発基盤への近さ	侵害時の事業影響を判断する

EPSSは、FIRSTが公開しているデータ駆動の予測指標だ。公開されたCVEが今後30日以内に悪用される確率を推定するため、CVSSやKEVとは別の観点を補える。

ただし、EPSSも万能ではない。スコアが低いから放置してよいわけではなく、外部公開された重要資産や、認証基盤に近い製品では自社影響を優先して見る。逆にEPSSが高くても、自社に対象がない場合は、監視や台帳更新に留められる。

初動では「対象資産の有無」を最初に確定する

CVEのニュースを見た直後に、いきなりパッチ適用の段取りへ進むと失敗しやすい。最初にやるべきことは、対象資産が自社に存在するかを確定することだ。

CVE初動対応チェックリストでは、対象製品、対象バージョン、露出範囲、暫定対策、記録・報告の順に確認する流れを整理している。KEV入りの脆弱性でも、この順番は変わらない。

確認対象は本番サーバーだけでは足りない。見落とされやすいのは次の場所だ。

検証環境や一時的に公開したデモ環境
VPN配下にある管理画面
子会社や委託先が運用する同一製品
開発者が個別に立てたコンテナやVM
古いアプライアンス、放置された管理ツール
SaaS連携やエージェント経由で入っているコンポーネント

特に、KEV入りした脆弱性はスキャンや悪用が早い。対象資産があるかどうかを曖昧にしたまま「後で確認する」にすると、実際には最も危険な時間帯を何もせずに過ごすことになる。

24時間・72時間・7日で分ける対応計画

脆弱性対応は「今日中に全部パッチ」だけでは回らない。業務停止のリスク、ベンダー更新の有無、検証時間、メンテナンス枠、委託先調整があるからだ。そこで、初動計画は時間軸で分ける。

時間軸	やること	完了条件
24時間以内	対象資産の有無、外部露出、KEV掲載、暫定遮断可否を確認する	影響あり・なし・調査中をチケットで分け、責任者を決める
72時間以内	パッチ適用、WAF/ACL、認証強化、監視強化、ログ確認を進める	外部露出資産の暫定リスクを下げ、悪用痕跡の有無を記録する
7日以内	恒久対応、例外承認、残リスク説明、台帳更新を完了する	経営・事業部・監査向けに判断根拠を説明できる状態にする

KEVに入っていて、外部公開され、管理権限や認証情報に近い製品なら、24時間以内に暫定遮断まで判断したい。パッチがすぐ当てられない場合でも、管理画面の公開停止、送信元制限、認証付きプロキシ、WAFルール、監視強化などでリスクを下げられることがある。

反対に、対象製品が存在しない、または社内限定で悪用条件が揃わない場合は、理由を残して監視へ回せる。大切なのは「何もしない」ことではなく、「確認した結果として優先度を下げる」ことだ。

経営や事業部へ説明するときの言い換え

セキュリティ担当者同士なら、KEV、CVSS、EPSS、CVE番号で会話できる。しかし経営や事業部には、そのまま伝えても判断材料になりにくい。

説明では、技術指標を事業影響に翻訳する。

技術的な表現	事業側に伝える表現
KEVに追加された	既に攻撃で使われた脆弱性として扱う必要がある
CVSS 9.8	技術的には重大で、条件が揃うと大きな影響が出る
外部公開資産に該当	社外から到達できるため、攻撃される可能性が高い
暫定緩和が必要	パッチ前に入口を閉じ、被害確率を下げる
例外承認が必要	すぐ直せない理由と残るリスクを責任者が確認する

この説明を先に作っておくと、緊急変更やメンテナンス枠の調整が速くなる。CVE番号とスコアだけを投げるより、「顧客データに近い公開管理画面で、悪用済みの脆弱性に該当するため、今日中に外部到達を止めたい」と言った方が、意思決定につながる。

よくある失敗：スコア表だけ、パッチだけ、例外だけ

KEVを使った優先順位付けで多い失敗は3つある。

1つ目は、スコア表だけで止まることだ。CVSS、EPSS、KEVの列を並べても、対象資産と露出が入っていなければ実務判断にならない。必ず資産台帳や外部公開状況と結びつける。

2つ目は、パッチだけを対応と見なすことだ。パッチ適用は重要だが、悪用済み脆弱性では、すでに侵害されていないかの確認も必要になる。アクセスログ、EDR、認証ログ、変更履歴、クラウド監査ログを見ずに「更新したので完了」とすると、侵害後の痕跡を見落とす。

3つ目は、例外管理が雑になることだ。業務都合でパッチを延期することはある。その場合でも、期限、理由、暫定対策、監視方法、承認者を残す必要がある。例外は免除ではなく、残リスクを引き受ける判断である。

参考情報

一次情報を確認するときは、次のページを起点にする。

国内運用では、ベンダー公式アドバイザリ、JPCERT/CC、IPA、利用中SaaSのステータスページも合わせて見る。ニュース記事だけで判断せず、必ず一次情報と自社資産情報へ戻る。

まとめ：KEVは脆弱性対応の順番を変える材料

KEVは、脆弱性対応の優先順位を決めるうえで強い材料になる。すでに悪用が確認された脆弱性は、単なる将来リスクではなく、現在進行形の攻撃面として扱うべきだからだ。

ただし、KEVだけで対応順は決まらない。CVSSで技術的な深刻度を見て、EPSSで悪用可能性の参考値を見て、外部露出と自社資産の重要度で事業影響を判断する。この5つを一枚のチケットにまとめるだけで、CVE対応はかなり落ち着いて進められる。

次に実務で使うなら、まず CVE初動対応チェックリストで確認項目を揃え、基礎を確認したい場合は脆弱性管理の基礎に戻るとよい。CVEとCVSSの役割が曖昧な場合は、先に CVEとCVSSの違いを読んでおくと、判断の言葉が整理しやすい。

KEVとは ─ CVSSだけに頼らない脆弱性対応の優先順位