KEVカタログで脆弱性対応の優先度を決める｜CVSSとの違い、期限の読み方、自社の一覧との突き合わせ方

脆弱性スキャナを回すと、数十〜数百件の CVE が並ぶことがあります。CVSS の点数で上から順に対応しようとしても、「9.8 が何十件もある」「7.5 だけど話題になっている」といった状態になり、どれから手をつけるべきか決めきれません。

このときの判断材料として使えるのが、CISA の KEV（Known Exploited Vulnerabilities）カタログです。この記事は、KEV に載る条件、CVSS や EPSS との違い、期限の読み方を一次情報で整理し、実際のカタログを集計した数字と、自社の一覧と突き合わせる手順をまとめます。

KEV に載る条件

CISA は KEV カタログを「実環境で悪用された脆弱性の権威ある情報源」と位置づけていて、次の3つをすべて満たしたものだけを載せます。

CVSS・EPSS・KEV は何が違うか

脆弱性の優先度付けでよく使われる3つの情報を並べます。

カタログの中身

カタログは Web ページのほか、CSV と JSON で配布されています。JSON の各項目には、主に次の値が入っています（CISA が公開しているスキーマより）。

数字で見る KEV（2026年9月11日版を集計）

JSON の全件を集計すると、次のようになりました。

追加された年ごとの件数は、2021年が311件、2022年が555件、2023年が187件、2024年が186件、2025年が245件でした。カタログが作られたのは2021年なので、最初の2年には過去の脆弱性がまとめて登録されています。

提供元ごとの件数では、Microsoft が388件で最も多く、Cisco（97件）、Apple（94件）、Adobe（81件）、Google（74件）と続きます。

目を引くのは直近の追加です。2026年9月の追加分には、ConnectWise ScreenConnect、GitLab、JFrog Artifactory、Citrix NetScaler、MikroTik RouterOS のほか、LiteLLM や Starlette、Kestra も入っていました。ネットワーク機器や OS だけでなく、開発者が自分で立てるサーバーやライブラリも普通に載るということです。LiteLLM は10月21日にも、版を固定していなかった環境に認証情報を盗む版が配られており、確認と復旧の記事にまとめています。

期限（dueDate）の読み方

期限を決めているのは BOD 26-04

KEV の期限は、CISA が2026年6月10日に出した拘束力のある運用指令 BOD 26-04（Prioritizing Security Updates Based on Risk）に基づいています。この指令で、KEV を作ったときの BOD 22-01 は廃止されました。

BOD 26-04 は、期限を CVSS の点数ではなく、次の4つの組み合わせで決めます。

KEV に載っている脆弱性の期限を、指令の表1から抜き出すとこうなります。

日数は暦日で、KEV に追加された日から数えます。KEV に載っていない脆弱性にも同じ表で期限があり、公開されていない機器で自動化もできないものは「次の定期的な更新のときに直す」とされています。

カタログの dueDate は、CISA が手元の情報で公開の有無などを判断して計算した日付です。実装ガイダンスは、公開された機器にあり、完全に制御でき、自動化できると判断した場合は3日の期限になると説明しています。最終的な公開の有無は、機器ごとに各機関が判断することになっています。

実際のカタログでも、2026年6月10日以降に追加された92件の期限は、3日が69件、14日が23件でした。

「3日＋侵害調査」が意味すること

表の「侵害調査」（forensic triage）は、期限内に対処したうえで、その機器がすでに侵害されていないかを調べることです。KEV に載っているということは、すでに攻撃に使われているということなので、更新を当てただけでは終わりにしない、という考え方です。

自社の一覧と KEV を突き合わせる

スキャナなどの結果から CVE 番号を取り出せれば、KEV との突き合わせは数行でできます。PowerShell なら次のとおりです。

$kev = Invoke-RestMethod "https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json"
"catalog: " + $kev.catalogVersion + " count: " + $kev.count
$mine = "CVE-2021-44228", "CVE-2026-85706", "CVE-2024-3094"
$kev.vulnerabilities | Where-Object { $mine -contains $_.cveID } |
  Select-Object cveID, vendorProject, dateAdded, dueDate, knownRansomwareCampaignUse |
  Format-Table -AutoSize

$mine の部分を、自社の一覧から取り出した CVE 番号に置き換えます。2026年9月13日に実行すると、次のように出ました。

catalog: 2026.09.11 count: 1709

cveID          vendorProject dateAdded  dueDate    knownRansomwareCampaignUse
-----          ------------- ---------  -------    --------------------------
CVE-2026-85706 GitLab        2026-09-11 2026-09-14 Unknown
CVE-2021-44228 Apache        2021-12-10 2021-12-24 Known

3件のうち、KEV に載っていたのは2件でした。表示されなかった CVE-2024-3094 は、この時点のカタログには載っていません。

前回の確認以降に追加された分だけを見るなら、日付で絞ります。

$since = "2026-09-06"
$kev.vulnerabilities | Where-Object { $_.dateAdded -ge $since } |
  Select-Object dateAdded, cveID, vendorProject, product

この日付より後に追加されたのは14件でした。確認した日を記録しておき、次回はその日以降だけを見ると、件数が増え続けても運用が続きます。

優先順位の付け方

BOD 26-04 の表は米国の連邦機関に向けたものですが、「公開されているか」「KEV に載っているか」を先に見るという考え方は、そのまま使えます。CISA も、連邦機関以外のあらゆる組織に KEV の脆弱性を優先して対処するよう強く勧めています。

実務では、次の順番で並べると判断がぶれにくくなります。

もう1つ注意したいのが、スキャナの結果そのものの正しさです。依存ライブラリの lock ファイルは新しいのに、動いているコンテナは古い、ということは珍しくありません。脆弱性スキャナが緑でも本番は古いことがあるにまとめたとおり、突き合わせる前に、一覧が実際に動いているものを表しているかを確かめてください。

KEV のほかに、CVE・NVD・EPSS・JPCERT/CC・JVN・GitHub Advisory Database などをどう組み合わせて情報を集めるかは、脆弱性情報の集め方で整理しています。

実際に KEV に加わった例として、2026年10月29日に追加された GitLab の脆弱性（CVE-2026-97229）があります。修正版が出てから17日で期限付きの一覧に入り、しかも最初の修正版では足りない別の脆弱性が続いていました。対象の確かめ方は GitLab の重大な脆弱性の記事で整理しています。同じ時期に VPN 装置の Ivanti Connect Secure でも、3つの脆弱性の連鎖が KEV に載っています（Ivanti Connect Secure の連鎖攻撃の記事）。修正の公開から KEV に載るまでの日数や期限の違いは、月ごとに 2026年のセキュリティ更新の記録へ追記しています。

よくある質問

日本の企業も KEV の期限に従う義務がありますか

ありません。BOD 26-04 が対象にしているのは米国の連邦政府の文民行政機関です。ただし CISA は、民間を含むあらゆる組織に KEV を脆弱性管理の優先順位付けに使うよう強く勧めています。

KEV はどのくらいの頻度で更新されますか

決まった曜日ではなく、悪用が確認されたものが随時追加されます。2026年は月に17〜31件のペースでした。JSON の dateReleased と catalogVersion で、手元のデータがいつの版かを確かめられます。

EPSS と KEV はどう使い分けますか

KEV は悪用が確認されたという事実、EPSS は今後30日以内に悪用される確率の推定です。まず KEV で「すでに使われているもの」を拾い、残りの中から EPSS で「次に危なそうなもの」を探す、という順番で組み合わせると重なりません。

CVSS が低い脆弱性でも KEV に載りますか

載ります。KEV の条件は深刻さの点数ではなく、悪用の証拠です。BOD 26-04 の表でも、技術的な影響が「一部」のものに3日や14日の期限が付いています。

まとめ

• KEV は悪用が確認された脆弱性の一覧。CVE 番号・悪用の証拠・対処方法の3条件で載る
• CVSS の基本値は深刻さ、EPSS は悪用の確率、KEV は悪用の事実。役割が違うので組み合わせて使う
• 2026年9月11日版は1,709件。ランサムウェアでの利用が確認されたものは360件。開発者が使うサーバーやライブラリも載る
• 期限は BOD 26-04 の表で決まり、公開された機器を完全に乗っ取られる種類なら3日＋侵害調査
• 自社の CVE 一覧と JSON を突き合わせ、確認した日以降の追加分だけを見る運用にする
• 載っていないことは安全の証明にならない

参考リンク

• CISA：Known Exploited Vulnerabilities Catalog
• CISA：Reducing the Significant Risk of Known Exploited Vulnerabilities（KEV に載る条件）
• CISA：KEV カタログの JSON スキーマ
• CISA：BOD 26-04 Prioritizing Security Updates Based on Risk
• CISA：BOD 26-04 Implementation Guidance
• FIRST：Exploit Prediction Scoring System (EPSS)
• FIRST：CVSS v4.0 User Guide
• 用語集：KEV Catalog
• 用語集：CVSS
• 脆弱性スキャナが緑でも本番は古いことがある｜lockと実体がずれる原因と確認方法