ほとんどの企業チームは、CISAのKnown Exploited Vulnerabilitiesカタログを天気予報と同じように扱っています。ヘッドラインが流れて（「CISAがKEVカタログに3件の脆弱性を追加」）、誰かが転送して、みんなが頷くだけ。それでは脆弱性管理で最も運用に役立つリストが台無しです。KEVは規模が小さく、マシンリーダブルで、ほぼ毎日更新され、リストの各エントリにはスキャナーの出力では得られない一つの特性があります。それは、実際に攻撃者が実在のネットワークで悪用したという事実です。

これはカタログ自体についてのガイドです。カタログが約束すること、約束しないこと、フィードの構造、自身の環境へのエントリのマッピング方法（自己欺瞞を避ける方法）、そしてEPSSやベンダーアドバイザリと組み合わせて防御可能なパッチ順序付けルールを作成する方法を解説します。ここで述べる内容はすべて、2026年7月下旬時点のライブフィードとCISAの公式ページで検証済みです。

KEVとは何か、何ではないか

CISAはKEVを実環境で悪用された脆弱性の権威ある情報源と位置づけています。エントリ登録には3つの基準があり、すべて満たす必要があります。

  1. 割り当て済みのCVE IDが存在すること。
  2. 実環境での悪用を示す信頼できる証拠が存在すること。
  3. ベンダー提供のアップデートなど、明確な修復アクションが存在すること。

これらの基準を除外条件として読むと、カタログの実際の形状が見えてきます。CVE IDがまだ割り当てられていない？悪用が横行していてもKEVには登録されません。悪用の報告はあってもCISAの証拠基準を満たさない？KEVには登録されません。悪用されていても修正や緩和策が存在しない？KEVには登録されません。カタログは精選された下限であって、国勢調査ではありません。2026.07.29リリース時点でフィードには1,656件のエントリが含まれていますが、毎年数万件のCVEが公開されるエコシステムと比べるとわずかです。KEVにないことは安全の証拠ではなく、KEVにあることは危険のほぼ証明です。この非対称性が本質であり、「ここにあるものはすべて緊急」ではなく「緊急なものはすべてここにある」という読み方が正しいのです。

分布も、何かを構築する前に知っておく価値があります。Microsoftが382件で最多、次いでCisco（95件）、Apple（93件）、Adobe（80件）、Google（72件）、そして近年大量悪用の主役となったアプライアンスベンダー：Ivanti（35件）、Fortinet（29件）。332件、約5件に1件に既知のランサムウェアキャンペーンフラグが付いています。典型的な企業スタックを実行している場合、このカタログの大部分はあなたを直接狙っています。

期限：BOD 22-01は廃止され、代替は基準を引き上げた

KEVは2021年11月のBinding Operational Directive 22-01によって作成され、米国連邦民間機関に対し、各登録CVEをエントリごとの期限までに修復することを義務づけました。KEVの期限について「新エントリは2〜3週間」という時代的イメージがまだあるなら、それは時代遅れです。2026年6月10日、CISAはBOD 26-04: Prioritizing Security Updates Based on Riskを発行し、BOD 22-01を完全に上書き・廃止しました。KEVカタログ自体は同一の登録基準で継続されますが、期限は4変数のリスクモデルで設定されるようになりました：資産の公開度、KEVステータス、悪用の自動化可能性、技術的影響（部分的 vs 完全制御）。修復タイムラインは最悪の組み合わせで3暦日（法医学的トリアージ必須）から、どの変数にも該当しない脆弱性では次回アップグレード時まで様々です。CISAのVulnrichmentプログラムは4変数のうち3つについてすべてのCVEの回答を公開しており、資産の公開度のみが各自で判断します。

体制変更はフィードで直接確認できます。6月10日以降に追加された39件のうち、34件が3日期限、残りが14日期限です。旧指令下では3週間が標準でした。データ取得日の具体例：Cisco Secure Firewall Management Centerのハードコードパスワード脆弱性CVE-2026-20316は2026-07-29に追加され、期限は2026-08-01。週末を挟んで3日間です。

連邦機関でなければ関係ないと思うかもしれませんが、2つの理由があります。第一に、期限は無料のトリアージです。あなたが決して見ることのないインシデントデータを持つ人々が算出した悪用速度と影響に関するCISAの判断をエンコードしています。データに基づく指令が「3日間」と言うとき、自分のインターネット露出FMCを30日チケット扱いするのは、少なくとも意識的に選択すべきことです。第二に、KEVはますます強制力のある場所に登場しています。サイバー保険の質問票、監査フレームワーク、顧客セキュリティレビューで、KEV登録脆弱性をどのように追跡・修復しているかを尋ねることが一般的です。「カタログを監視し、露出資産に連邦期限を適用している」という回答は、実現にほとんどコストがかからず、クリーンで防御可能です。

フィード：Webページをスキップし、データを消費する

閲覧可能なカタログページは人間向けには問題ありませんが、運用インターフェースはすべて無料・認証不要のフィードです。

  • JSON: https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json
  • CSV: https://www.cisa.gov/sites/default/files/csv/known_exploited_vulnerabilities.csv
  • JSONスキーマ: https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities_schema.json

JSONドキュメントは小さなエンベロープ（title、catalogVersion、dateReleased、count）とvulnerabilities配列を持ちます。各エントリは以下のフィールドを持ちます：cveID、vendorProject、product、vulnerabilityName、dateAdded、shortDescription、requiredAction、dueDate、knownRansomwareCampaignUse（文字列KnownまたはUnknown）、notes（セミコロン区切りのアドバイザリURL）、cwes。

以下は、フィードを取得して指定ベンダーに一致する最近の追加を表示する、プレーンなNode.js（18以上、依存関係なし）の最小ウォッチャーです。この記事執筆中にこのスクリプトをライブフィードに対して実際に実行しました。

// kev-watch.mjs - Node 18+ (native fetch, top-level await)
const FEED = "https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json";
const KEYWORDS = ["cisco", "vmware", "broadcom", "windows server", "solarwinds"];
const DAYS_BACK = 30;

const res = await fetch(FEED);
if (!res.ok) throw new Error(`KEV feed returned HTTP ${res.status}`);
const { catalogVersion, count, vulnerabilities } = await res.json();

const cutoff = new Date(Date.now() - DAYS_BACK * 86_400_000);
const matches = vulnerabilities.filter((v) => {
  const haystack = `${v.vendorProject} ${v.product}`.toLowerCase();
  const recent = new Date(v.dateAdded) >= cutoff;
  return recent && KEYWORDS.some((k) => haystack.includes(k));
});

console.log(`KEV ${catalogVersion} (${count} total entries)`);
console.log(`${matches.length} matches added in the last ${DAYS_BACK} days:\n`);

for (const v of matches.sort((a, b) => a.dueDate.localeCompare(b.dueDate))) {
  const flag = v.knownRansomwareCampaignUse === "Known" ? "  << RANSOMWARE" : "";
  console.log(`due ${v.dueDate}  ${v.cveID}  ${v.vendorProject}: ${v.product}${flag}`);
}

Enter fullscreen mode Exit fullscreen mode

2026-07-29の実出力：

KEV 2026.07.29 (1656 total entries)
2 matches added in the last 30 days:

due 2026-07-16  CVE-2008-4128  Cisco: IOS
due 2026-08-01  CVE-2026-20316  Cisco: Secure Firewall Management Center (FMC)

Enter fullscreen mode Exit fullscreen mode

任意の方法でスケジュールし、メールやチャットにパイプしてください。このアイデアのより完全なバージョン、MicrosoftのMSRCフィードも取り込み、ファームウェアバージョンのコンプライアンスドリフトをチェックする日次ブリーフが必要な場合は、別の記事で構築手順を説明しました：Build a 5-minute morning security brief。本記事はカタログ自体に留まります。

KEVを自身の環境にマッピングする：偽陰性トラップ

vendorProjectとproductに対するキーワードマッチングは、すべての自作KEVコンシューマーが最初に行うことであり、ほとんどの場合、静かに腐敗する場所です。これらのフィールドは人間が書いた文字列で、統制語彙ではなく、素朴なフィルタを少なくとも3つの方法で裏切ります。

第一に、ベンダー名が変更されます。Broadcom買収前のVMwareエントリはvendorProject: "VMware"に、新規エントリ（vCenter ServerやAria Operationsを含む）は"Broadcom"に置かれます。vmwareのみに一致するフィルタは、新しいvCenter KEVを見逃します。製品名変更にも同じ問題が当てはまります。上記のCisco FMCエントリは説明に「旧称Firepower Management Center」と親切に記載していますが、将来のエントリに同じことを強制する仕組みはありません。

第二に、曖昧な製品文字列。Zyxelのproduct: "Multiple Products"のようなエントリは、合理的な製品キーワードに一致しません。製品名だけでフィルタすると、これらは消えます。

第三に、インベントリが嘘をつきます。フィードとのマッチングは簡単な半分です。難しい半分は、エントリ内のものが実際にネットワーク上に存在すること（2019年にラックされたがCMDBに入らなかったアプライアンスを含む）を把握することです。

アプローチを正直に保つ実践的なルール：製品単独ではなくベンダーと製品の連結でマッチングする；レガシーベンダー名と並んで買収者名を含める（VMwareとBroadcom、SolarWindsとN-ableなど）；キーワードリストはカタログが驚かせたときにレビューされる設定として扱う；そして週に一度、マッチングに関係なく新規追加の全リストを目視確認する（現在のボリュームでは2026年だけで172件追加、2分のざっと見で済む）。キーワードフィルタはトリップワイヤーであって、カバレッジ保証ではありません。保証が必要なら、CPEベースマッチングを持つスキャナーがそのためのものであり、それらでさえ互いに一致しません。

ランキングルール：KEV、次にEPSS、次にベンダーアドバイザリ

KEVが答える質問は1つだけです。「これは悪用されているか？」それ以外のこと、つまり他のすべての悪用の可能性や、悪用された場合の自身への影響については何も言いません。そこで3つのシグナルをこの順序で組み合わせます。

  1. KEVメンバーシップはゲートであってスコアではない。 自身の環境に存在するKEV内のものは、例外なくキューの先頭に行きます。そのセット内でdueDateで順序付けし、knownRansomwareCampaignUse: "Known"エントリを最初に置きます。露出度がカレンダーを決めます。インターネット露出資産の場合、CISAの期限を自身の期限として扱います。内部専用資産の場合、次回予定ウィンドウが通常は防御可能です。これがまさにBOD 26-04の露出変数の精神です。

  2. EPSSはKEVが沈黙するすべてをランク付けする。 FIRSTのExploit Prediction Scoring SystemはCVEが今後30日以内に悪用される確率を推定し、無料APIはCVEごとに1回のGETリクエストです。KEVが確認的であるのに対し、EPSSは予測的であるため、KEVを補完します。ただし、継ぎ目の盲点を知っておく必要があります。新規KEVエントリには、まだ意味のあるEPSSスコアがないことが多いのです。CVE-2026-20316がカタログに登録された日、EPSSには全くスコアがありませんでした。一方、2008年製のCisco IOSエントリは0.33で、全CVEの98パーセンタイル以上でした。KEV優先、EPSS次点は単なるスローガンではなく、順序が負荷を支えています。

  3. ベンダーアドバイザリが実際に何をするかを決める。 すべてのKEVエントリはnotesフィールドにアドバイザリをリンクしています。アドバイザリは修正バージョン、回避策の有無、特定の設定が影響を受けるかどうかを教えてくれます。Cisco環境では、KEVがFMCが活発に攻撃されていることを教えてくれます。Ciscoアドバイザリのみが、リリース列車に修正ビルドがあるかどうか、ウィンドウが開くまでの緩和策が何かを教えてくれます。

1行ポリシーとして：露出資産でKEVマッチならCISAの時計で今すぐパッチ。内部専用KEVマッチなら次回ウィンドウ、ランサムウェアフラグ付きを優先。KEVマッチなしならEPSSと重要度でランク付けし、通常のペースで処理し、修正自体の情報源としてベンダーアドバイザリを真実とする。

正直な限界

KEVは脆弱性管理で最高の無料シグナルですが、それでも特定の予測可能な方法で失敗します。

設計上遅れます。 実環境悪用の証拠が存在し、CISAの基準に達するまでエントリは表示されません。パッチが存在する前に悪用されているゼロデイの場合、基準3が修正が出荷されるまで登録をブロックし、エントリが着いた時点で攻撃者に数日遅れを取っている可能性があります。KEVは重要資産の製品に対する早期警告システムにはなり得ません。ベンダーPSIRTフィードと緊急アドバイザリがそのウィンドウを所有します。また反対方向にも遅れます。2026年7月に追加されたCisco IOSエントリはCVE-2008-4128、18年前の脆弱性です。悪用の証拠は到着したときに到着します。

重大度や適用性の文脈を持ちません。 エントリはスコアリングされておらず、期限は連邦ネットワーク向けのCISAリスクモデルを反映しており、自身の露出を反映していません。同一期限の2つのエントリでも、自身にとっての意味は大きく異なる可能性があります。カタログは、製品を持っているかどうか、到達可能かどうか、または補償制御がすでに悪用経路をブロックしているかどうかを知ることができません。これは優先順位付けへの入力であって、優先順位付けそのものではありません。

一部のエントリはデッドウェイトで、稀に完全に死んでいるものもあります。 成長し続けるカタログは、何年も前にEOLを迎えた製品のエントリを蓄積します。それらはEOL機器がまだラックされている場合には重要ですが、素朴なダッシュボードを乱雑にします。また、証拠基準は高いものの infallible ではありません。CISAは2023年12月にD-Linkの「脆弱性」が実際には存在せずCVEが却下されたため、CVE-2022-28958をカタログから削除しました。削除はニュースになるほど稀で、それ自体が良い兆候ですが、フィードを下流の何かにミラーリングする場合は、追加だけでなく削除も同期してください。

これらのどれもカタログに反対するものではありません。完全なリスク像として扱うのではなく、それが実際に何であるか——ほぼ毎日更新され、システム管理者が30行のコードで消費できる、証明された攻撃者行動の短く高信頼性のリスト——として扱うことに反対するものです。ほとんどの組織はそれすら行っていません。それを行っている組織になりましょう。

Adam Lewandowskiは、Cisco FTD/FMC/ISE、Windows Server、MECM、VMware環境を扱うネットワーク・セキュリティエンジニア（CompTIA Security+、CCNA、VMware VCP-DCV）です。LinkedInでつながることができます。

私はThe Patch Windowという、待てない企業向けパッチ（Cisco、Windows Server、VMware）を扱う無料の週5分ブリーフを書いています。購読：https://the-patch-window.beehiiv.com