CISA KEVとは?「実際に狙われている」だけを集めた公式リスト|2026年のルール変更まで

セキュリティ用語をやさしく / 2026年8月版

CISA KEVとは?「実際に狙われている」だけを集めた公式リスト

世の中には何万件もの脆弱性があります。そのうち「実際に攻撃者が使っていることが確認されたもの」だけを、米国政府が公式に列挙しているのがKEVカタログです。全部で1,662件。数万件の中から絞り込まれた、この1,662件が優先順位のすべてを決めます。

脆弱性の情報を追いかけようとすると、すぐに数の壁にぶつかります。毎年数万件のCVEが公開され、そのすべてに目を通すことは誰にもできません。

そこで役に立つのがKEVカタログです。正式名称は「Known Exploited Vulnerabilities Catalog(既知の悪用された脆弱性カタログ)」。米国のCISA(サイバーセキュリティ・インフラセキュリティ庁)が運営しています。

KEVの考え方はとてもシンプルです。「理論上あぶないもの」ではなく「実際に使われていることが確認されたもの」だけを載せる。 それだけです。

⚠ この記事を読む前に:KEVは「全部」ではありません

KEVは悪用が公式に確認できたもののリストです。世界中で起きているすべての悪用を把握しているわけではありません。「KEVに載っていない=安全」ではない、という点だけは最初に押さえてください。KEVは優先順位を上げるための材料であって、安全証明書ではありません。

CHAP1

第1章 / 全7章

KEVは「悪用が確認された」リスト

脆弱性への対応でいちばん難しいのは、技術そのものではなく「どれから手をつけるか」です。手が足りない、時間がない、止められないシステムがある。そういう現実のなかで優先順位をつけなければなりません。

長いあいだ、その判断にはCVSSという点数が使われてきました。0.0〜10.0で深刻さを表す指標です。ところがCVSSには弱点があります。それは「もし攻撃が成立したらどれくらい重大か」という理論値であって、「実際に狙われているか」を表していないのです。

CVSSが9.8でも誰も使っていない脆弱性はたくさんあります。逆に、CVSSが5.3でも今まさに攻撃に使われているものがあります。KEVは、この後者を拾い上げるために作られました。

CISAによる位置づけ

CISAは、KEVカタログを「実際に悪用された脆弱性の、権威ある情報源」と位置づけています。そしてすべての組織に対して、KEVカタログを確認・監視し、掲載された脆弱性の修正を優先するよう強く推奨しています。米国政府機関だけのものではありません。

第1章 おわり — 次は第2章
CHAP2

第2章 / 全7章

載る条件は3つだけ

KEVに載る基準は、CISAが公式に3つだけ定めています。この3つをすべて満たしたものが掲載されます。

#条件意味
1CVE IDが割り当てられている公式な脆弱性番号がついていること。番号のない噂話は載らない
2実際に悪用されたという信頼できる証拠がある「悪用されうる」ではなく「悪用された」。ここがKEVの核心
3明確な修正方法があるベンダーの更新プログラムなど、対処する手段が存在すること

2つ目が決定的です。CISAは、「悪用可能(exploitable)」と「悪用された(exploited)」を明確に区別しています。

「悪用可能」は、攻撃のしやすさを表す評価です。実証コード(PoC)が公開されているか、ネットワーク越しに届くか、特権が要らないか、といった条件から判断されます。しかしこれはあくまで可能性の話です。KEVが求めるのは、それが実際に行われたという証拠のほうです。

3つ目の「修正方法がある」も見落とされがちですが重要です。KEVは行動できるリストであることを重視しています。直しようがないものを載せても、受け取った側は動けないからです。

第2章 おわり — 次は第3章
CHAP3

第3章 / 全7章

誰に効力があるのか

KEVには法的な強制力がある部分と、ない部分があります。ここを混同すると話が噛み合わなくなります。

対象KEVの扱い
米国の連邦民生行政機関(FCEB)義務。定められた期限内に修正しなければならない
米国の州・地方・部族・準州の政府(SLTT)義務ではないが、CISAが強く推奨
民間企業義務ではないが、CISAが強く推奨
日本を含む米国外の組織義務ではない。ただし情報としては誰でも同じものが使える

この「義務」の根拠になっているのがBOD(Binding Operational Directive/拘束力のある運用指令)という仕組みです。米国国土安全保障省が連邦機関に対して出す、強制力のある指示のことです。

KEVカタログは2021年11月、BOD 22-01によって創設されました。当サイトのデータベースでも、KEVの最も古い登録日は2021年11月3日で、BOD 22-01の発行日と一致しています。

日本の組織にとっての意味

日本の企業や個人にKEVへの法的義務はありません。しかし攻撃者は国境を気にしません。KEVに載っているのは「世界のどこかで実際に使われた」脆弱性であり、その製品を日本で使っていれば同じリスクにさらされます。義務がないことと、無関係であることは別です。

第3章 おわり — 次は第4章
CHAP4

第4章 / 全7章

2026年6月、ルールが変わった

ここは日本語の解説記事ではまだあまり触れられていない話です。KEVの運用ルールは、2026年6月に大きく変わりました。

2026年6月10日、CISAはBOD 26-04「リスクに基づくセキュリティ更新の優先順位付け」を発行しました。これはBOD 22-01(2021年11月3日/KEVを創設した指令)とBOD 19-02を正式に廃止し、置き換えるものです。KEVカタログの掲載基準そのものは引き継がれましたが、「いつまでに直すか」の決め方が根本的に変わりました

BOD 22-01(2021年11月〜)BOD 26-04(2026年6月〜)
期限の決め方KEVに載ったら一律の期限4つの変数の組み合わせで段階的に決まる
KEVの位置づけそれ自体が対象リスト判断に使う4変数のうちの1つに格下げ(ただし重みは大きい)
CVSSの扱い併用点数ベースの期限設定から離れる
低リスクの扱い意図的に後回しにしてよいと明示

新しい判断基準になった4つの変数はこれです。

変数問い
Asset Exposure(資産の露出)その機器はインターネットに公開されているか?
KEV Status(KEV収載)その脆弱性はKEVカタログに載っているか?
Exploit Automation(悪用の自動化)攻撃の全手順を自動化できるか?
Technical Impact(技術的影響)成功すると部分的な制御か、完全な制御か?

この4つの答えの組み合わせで、修正期限が3日・14日・60日の3段階に振り分けられます。4つすべてが最も危険な側に振れた場合が、3日です。

私たちのデータでも、この変化が観測できました

当サイトではKEVカタログを継続的に取り込んでいます。登録された脆弱性に付いた「是正期限までの日数」を年ごとに数え直すと、政策の変化がそのまま数字に出ていました。

登録年件数是正猶予の中央値背景
2021年311181日KEV創設。既存の脆弱性をまとめて登録した時期
2022年55521日BOD 22-01の運用が安定。4年間ずっと21日
2023年18721日
2024年18621日
2025年24521日
2026年17814日年の途中でルールが変わったため中間の値になる
うち2026年6月以降553日BOD 26-04の発行後。55件中45件が3日

4年間ずっと21日だった猶予が、2026年6月を境に3日になっています。 週明けに対応しよう、今月中に計画を立てよう、という進め方が通用しない世界に入ったということです。

CISA自身が、BOD 26-04の背景でその理由を述べています。攻撃者によるAIの利用が、修正プログラムの公開から悪用までの猶予をさらに狭める可能性がある——だから、すべての脆弱性を平等に扱うのをやめ、リスクの高いところに集中する、という考え方です。

🚨 重要:「3日」は米国政府機関の義務であって、日本の民間企業の義務ではありません

誤解しないでください。BOD 26-04が拘束するのは米国の連邦民生行政機関だけです。日本の企業が3日以内に対応する法的義務はありません。ただしこの3日という数字は、「攻撃者がどれくらいの速さで動いているか」についての、米国政府の現時点での見積もりです。義務ではなく、脅威の速度を示す指標として読むのが正しい使い方です。

第4章 おわり — 次は第5章
CHAP5

第5章 / 全7章

1,662件を数字で見る

KEVカタログには、2026年8月8日時点で1,662件が登録されています。最も古い登録日は2021年11月3日、最も新しいものは2026年8月7日です。中身を集計してみます。

どのベンダーの製品が多いか

順位ベンダー件数全体に占める割合
1Microsoft38223.0%
2Cisco955.7%
3Apple935.6%
4Adobe804.8%
5Google724.3%
6Oracle452.7%
7Apache402.4%
8Ivanti352.1%
9Fortinet291.7%
10VMware / Linux / D-Link各26各1.6%

Microsoftが4分の1近くを占めています。ただしこれは「Microsoftが危険だ」という意味ではありません。 使われている数が圧倒的に多ければ、攻撃者にとっての費用対効果も高くなり、狙われる回数も増えます。KEVの件数は、危険度ではなく「攻撃者にとっての人気度」に近いと考えるのが正確です。

ランサムウェアに使われたもの

KEVカタログには、それぞれの脆弱性がランサムウェア攻撃に使われたことが分かっているかを示す欄があります。

ランサムウェアでの使用件数割合
使用が判明している33820.3%
不明1,32479.7%

5件に1件が、ランサムウェアで使われたことが確認されています。 「不明」の79.7%は「使われていない」という意味ではなく、あくまで確認が取れていないという意味です。この欄は、対応の優先順位をさらに絞り込みたいときに役立ちます。

第5章 おわり — 次は第6章
CHAP6

第6章 / 全7章

KEVの限界を知っておく

便利なリストですが、万能ではありません。使う前に知っておくべき性質が4つあります。

性質何が起きるかどう扱うか
全数ではない公表されていない悪用、確認が取れていない悪用は載らない「載っていない=安全」と読まない
CVEの公開より先に載ることがある当サイトが追跡する防御製品ぶんの111件では、25件(約4件に1件)がCVEの公開日と同日かそれ以前にKEVへ登録されていた「詳細が出てから考える」では間に合わない場合がある
何年も前のCVEが後から載る同じ111件で、CVE公開からKEV収載までの最長は約9年(中央値は49日)古い機器を「もう情報が出ないから安全」と考えない
米国の視点である米国の政府機関や重要インフラで観測された事象が中心になりやすい日本固有の被害はJPCERT/CCやIPAの情報で補う

2つ目は特に意外に思われるかもしれません。脆弱性の詳細が公式データベースに載るより先に、CISAが「もう悪用されている」と宣言するケースが、4件に1件あるということです。攻撃のほうが情報公開より速い、という現実がここに表れています。

やってはいけない使い方

「KEVに載っていないから、この脆弱性は放置してよい」——これがいちばん危険な読み方です。KEVは優先度を上げるための材料であって、下げるための材料ではありません。載っていないものは「まだ確認されていない」だけで、安全とは限りません。

第6章 おわり — 次は第7章
CHAP7

第7章 / 全7章

日本の私たちはどう使うか

KEVは誰でも無料で見られます。CISAのサイトで公開されており、CSVやJSON形式でダウンロードもできます。とはいえ、1,662件を毎日眺めるわけにもいきません。立場別の使い方をまとめます。

立場KEVの使い方
個人・家庭直接見る必要はほぼありません。スマホ・パソコン・ルータの自動更新を有効にしておけば十分です。ニュースで「悪用が確認されている」と言われたら、それがKEVの話だと分かれば上出来
中小企業のIT担当自社で使っているベンダー名でKEVを検索し、該当があれば最優先で更新する。とくにVPN装置・ファイアウォールなどインターネットに面した機器から
セキュリティ担当脆弱性管理ツールにKEVを取り込み、自動でフラグを立てる。CISAもツールによる自動化を推奨している
経営層・意思決定者「CVSSが高い順に対応」という報告が上がってきたら、「KEVに載っているものから対応しているか」を確認する

今日から使えるチェックリスト

  • 自社・自宅でインターネットに直接つながっている機器を一覧にした
  • その機器のベンダー名でKEVカタログを検索してみた
  • 脆弱性の対応順をCVSSの点数だけで決めていないか確認した
  • 「KEVに載っていない=安全」と解釈していないか、チーム内の認識を確認した
  • ランサムウェアでの使用が判明しているものを、さらに優先していないか検討した
✅ まとめ:最初にやること3ステップ

1. CISAのKEVカタログを一度開いてみる(無料・登録不要・CSVでダウンロード可)。
2. 自分が使っている製品のベンダー名で検索してみる。1件も無ければ、ひとまず安心材料になる。
3. 該当があれば、更新プログラムが当たっているかを確認する。当たっていなければ、それが今いちばん優先すべき作業です。

KEVを実際に数え直すと何が見えるか

当サイトでは、このKEVカタログを使ってセキュリティ製品78本の脆弱性を分析しています。3,993件のうち実際に悪用されたのは111件(2.8%)で、報告件数1位のクロスサイトスクリプティング385件は悪用ゼロ、逆に報告25件しかない「認証のかけ忘れ」が悪用最多タイでした。KEVという物差しが何を見せてくれるかの実例です。

いちばん多い欠陥は、いちばん悪用されない を読む
第7章 おわり — 次はよくある質問
 FAQ

よくある質問

KEVについてよくある質問

KEVは日本語で見られますか?

CISAの公式カタログは英語のみです。ただし製品名とCVE番号が中心なので、英語が苦手でもベンダー名で検索する使い方は十分できます。日本語で脆弱性を調べたい場合は、IPAとJPCERT/CCが運営するJVN iPediaが便利です。

KEVとCVE、CVSSはどう違うのですか?

CVEは「どの1件か」を表す番号、CVSSは「もし成立したらどれくらい深刻か」の点数、KEVは「実際に悪用されたか」の事実です。答えている問いがそれぞれ違います。詳しくはCWEとは?CVEとの違いを10分でで、CWE・EPSSも含めた5つを1枚の表に整理しています。

なぜ「3日」なのですか?短すぎませんか?

BOD 26-04で3日が適用されるのは、4つの変数すべてが最も危険な側に振れた場合だけです。つまり「インターネットに公開されていて、KEVに載っていて、攻撃を自動化でき、成功すると完全に乗っ取られる」という条件が揃ったときです。すべての脆弱性が3日というわけではありません。低リスクのものは意図的に後回しにしてよい、とも明記されています。

日本の企業もBOD 26-04に従う必要がありますか?

法的な義務はありません。BODが拘束するのは米国の連邦民生行政機関だけです。ただしKEVカタログ自体は誰でも利用でき、CISAはすべての組織に活用を推奨しています。義務としてではなく、脅威の速度を知る材料として使うのが現実的です。

KEVに載っていない脆弱性は無視していいですか?

いいえ。KEVは優先度を上げるための材料であって、下げるための材料ではありません。載っていないものは「悪用がまだ確認されていない」だけです。特に自社の重要システムに関わるものは、KEVの有無にかかわらず対応を検討してください。

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

随時更新されます。当サイトが2026年8月8日に取得した時点で、最も新しい登録日は前日の2026年8月7日でした。週に複数回追加されることも珍しくありません。

BOD 22-01はもう無効なのですか?

はい。BOD 26-04が、BOD 22-01(2021年11月3日)とBOD 19-02(2019年4月29日)を正式に廃止しました。ただしKEVカタログへの掲載基準(3つの条件)はBOD 26-04にそのまま引き継がれているため、KEVそのものの性質は変わっていません。変わったのは修正期限の決め方です。

出典・参照

コメント