CISA KEV：既知の悪用された脆弱性カタログとは

CISA KEVカタログとは

Known Exploited Vulnerabilities（KEV）カタログは、米国のサイバーセキュリティ・インフラストラクチャセキュリティ庁（CISA）が管理しています。CISAはこれを実際に悪用された脆弱性の信頼できる情報源と位置付けており、すべての組織に対してこれらの修正を優先するよう強く推奨しています。

CISAは2021年11月、拘束力のある運用指令（BOD）22-01とともにこのカタログを開設しました。2026年9月24日版のカタログには1,723件の脆弱性が掲載されています。これは公開されているCVE全体のごく一部にすぎませんが、だからこそ役に立ちます。KEVへの掲載は予測や深刻度の評価ではなく、悪用の記録なのです。

脆弱性が追加される条件

CISAは、次の3つの条件を満たす脆弱性を追加します。

CVE IDがあること。
実際に悪用されていること。過去に悪用された、または現在悪用されているという信頼できる証拠があること。
明確な修正ガイダンスがあること。ベンダーのアップデートなど、影響を受ける組織が取るべき明確な対応があること。

3つ目の条件は実務上重要です。参照できる修正がなかったために、脆弱性がKEVに掲載されるまでの間、しばらく悪用され続けることがあるからです。CISAのKEVページにリンクされたフォームから、誰でも脆弱性を推薦できます。

各KEVエントリーの内容

フィールド	内容
`cveID`	CVE識別子
`vendorProject`、`product`	影響を受けるソフトウェアの開発元と製品
`vulnerabilityName`、`shortDescription`	名称と短い説明
`dateAdded`、`dueDate`	CISAが追加した日付と、米国連邦機関の修正期限
`requiredAction`	取るべき対応。通常はベンダーのアップデートや緩和策の適用、または使用の中止
`knownRansomwareCampaignUse`	ランサムウェアキャンペーンで使われたことがあれば「Known」、そうでなければ「Unknown」
`forensicTriage`	BOD 26-04がフォレンジックトリアージを求めている場合は「Yes」
`notes`、`cwes`	参考情報と脆弱性の種類

現在361件のエントリーが、ランサムウェアキャンペーンで使われたものとしてマークされています。KEVの中で順位を付ける必要がある場合は、これらを最優先にします。

BOD 26-04：連邦機関に対するKEVの期限

米国連邦文民行政機関にとって、KEVは助言ではありません。2026年6月10日に発令された拘束力のある運用指令26-04は、修正までの期限を定めています。この指令により、大半のKEVエントリーに2週間、2021年より前に割り当てられたCVEに6か月の期限を設けていたBOD 22-01と、BOD 19-02が廃止されました。KEVに脆弱性を追加する条件は変わっていません。

BOD 26-04は、CISAのSSVC意思決定モデルを踏まえ、4つの問いから各期限を定めます。

公開されているか：その資産にパブリックネットワークから到達できるか。
KEVの状況：その脆弱性はカタログに掲載されているか。
悪用の自動化：攻撃者は悪用を自動化できるか。
技術的影響：悪用によって部分的な制御、または完全な制御を得られるか。

回答に応じて、期限は3日（システムがすでに侵害されていないかを確認するフォレンジックトリアージを伴う）から、次回のシステムアップグレード時の修正までの幅があります。契約で定められていない限り、この指令は連邦政府以外の企業には適用されません。それでも、自社のポリシーを考えるうえで有用な基準になります。

ソフトウェアを開発する企業のKEVの使い方

KEVエントリーの大半は大手ベンダーの製品のものです。Microsoftだけで388件を占め、Cisco、Apple、Adobe、Googleが続きます。オープンソースも登場し、その場合は他社の製品の中に含まれています。誰もが覚えている例がLog4Shell（CVE-2021-44228）です。

ビルドパイプラインも例外ではありません。侵害されたGitHub Actionsのtj-actions/changed-files（CVE-2025-30066）とreviewdog/action-setup（CVE-2025-30154）は、いずれもカタログに掲載されています。既知の悪用された脆弱性は、製品の中だけでなく、製品をビルドするワークフローにも潜んでいる可能性があります。

リポジトリが宣言しているものではなく、出荷するものとKEVを照合する。推移的に取り込まれた脆弱なライブラリや、ビルドスクリプトがダウンロードしたライブラリも、製品の中に含まれています。
一致したものはバックログ項目ではなくインシデントとして扱う。修正するか、緩和してその理由を記録します。
影響を受けていた期間を確認する。どのリリースが脆弱なバージョンを出荷していたのか、いつからなのか。顧客が尋ねるのはまさにそこです。
報告の期限に注意する。EUのCyber Resilience Actでは、製品内の実際に悪用されている脆弱性について、メーカーに24時間以内の早期警告の義務が生じます。
その他のすべてに順位を付ける。EPSSとCVSSを使います。手法については脆弱性の優先順位付けで解説しています。

KEVのデータを入手する方法

CISA：カタログのページに加え、CSV、JSON、JSONスキーマ。
GitHub：cisagov/kev-dataがデータファイルをミラーしており、カタログの更新に合わせて更新されます。
メール：CISAはカタログ更新の購読サービスを提供しています。
自社のツール：Grype、Tenable、Qualys、Rapid7など、多くのスキャナーや脆弱性管理プラットフォームがKEVエントリーを表示します。

CRACIでできること

KEVはどの脆弱性が悪用されているかを教えてくれます。CRACIはそれがどこにあるかを教えてくれます。CRACIはGitHub Actionsのジョブを実行し、推移的依存関係、キャッシュされたパッケージ、ロックファイルに記載されない隠れた依存関係を含め、各ジョブが実際に取得したパッケージを記録し、監視対象のSBOMを継続的に再評価します。

影響を受けるビルドの特定。ビルド履歴により、過去のどのビルドに直接または推移的な脆弱な依存関係が含まれていたかがわかるため、影響を受けていた期間を把握できます。
修正の担当者。セキュリティチームは検出結果をトリアージし、それぞれを修正を担当するチームに振り分けます。
再出荷の防止。ポリシーゲートにより、特定のCVEを含むビルドをブロックできます。
報告。CRAのもとで実際に悪用されている脆弱性については、CRACIが通知の内容を準備し、メーカーの担当者がSingle Reporting Platformを通じて提出します。

CISA KEVに関するよくあるご質問

CISA KEVとは何ですか？

Known Exploited Vulnerabilities（KEV）カタログは、実際に悪用された脆弱性をまとめたCISAのリストです。CISAはこれを悪用された脆弱性の信頼できる情報源と位置付け、すべての組織に対してこれらの修正を優先するよう推奨しています。

KEVカタログには何件の脆弱性が掲載されていますか？

2026年9月24日版のカタログで1,723件です。公開されている数十万件のCVEのうちの一部です。そのうち361件は、ランサムウェアキャンペーンで使われたことが知られているものとしてマークされています。

脆弱性がKEVに追加される条件は何ですか？

3つの条件があります。CVE IDがあること、過去に悪用された、または現在悪用されているという信頼できる証拠があること、そしてベンダーのアップデートなど明確な修正ガイダンスがあることです。

民間企業もKEVの期限に従う必要がありますか？

いいえ。期限が拘束力を持つのは、拘束力のある運用指令26-04のもとにある米国連邦文民行政機関です。それ以外の組織は、カタログを優先順位付けの指標として活用できます。多くの顧客や監査人もそれを期待しています。

BOD 22-01は何に置き換えられましたか？

2026年6月10日に発令されたBOD 26-04が、BOD 22-01とBOD 19-02を廃止しました。KEVエントリーに一律2週間の期限を設けるのではなく、KEVの状況、公開の有無、悪用を自動化できるかどうか、技術的影響に基づいて、3日から次回のシステムアップグレードまでの期限を定めています。

KEVとEPSSの違いは何ですか？

KEVはすでに悪用されている脆弱性を記録します。EPSSは、公開されているCVEが今後30日以内に悪用される確率を推定します。まずKEVを使い、その他のすべての順位付けにEPSSを使います。