メインコンテンツへスキップ
Securify
トライアル
Securify

CISA KEVカタログとは？悪用済み脆弱性の確認と対応への使い方

セキュリティ解説Securify編集部読了目安 約 14 分
目次29項目
CISA KEVカタログとは？悪用済み脆弱性の確認と対応への使い方

はじめに：脆弱性対応の現場が直面する深刻な課題

毎日のように新たな脆弱性が公開される中、あなたの組織はどの脆弱性から対処していますか？CVSSスコアが高いものから？それとも公開された順番に？

実は、公開された脆弱性のうち、実際に悪用が確認されるのは一部に過ぎません。Kenna Security（現Cisco）とCyentia Instituteによる複数年にわたる調査では、次のような結果が報告されています。

  • 2019年の調査では、同年に新たに登録された18,000件のCVEのうち、実際に悪用されていたのは473件（2.6%）でした
  • 2021年の調査では、同年に報告された20,130件の脆弱性のうち、組織にとって高リスクとされたのはわずか4%でした

これらの調査は、公開された脆弱性のすべてが同じように攻撃に使われるわけではないことを示しています。CVSSは脆弱性の技術的な深刻度を示す指標であり、CVSSスコアが高いことと、実際に攻撃で使われていることは同じではありません。悪用されているかどうかは、別の情報で確かめる必要があります。

CVSSスコアだけで優先順位を決めると、限られたリソースを、実際には攻撃に使われていない脆弱性の対応に費やしてしまう可能性があります。その一方で、攻撃に使われている脆弱性への対応が後回しになれば、被害を受けるリスクが高まります。

「どの脆弱性から対処すべきか分からない」

「全ての脆弱性に対応するリソースがない」

「優先順位の判断基準が欲しい」

こうした現場の悩みに応える手がかりの一つが、米国CISAが提供するKEV（既知の悪用された脆弱性カタログ）です。本記事では、KEVの基本から実践的な活用方法、そして包括的なセキュリティ対策までを徹底解説します。

KEV（Known Exploited Vulnerabilities）とは何か

KEVの定義と本質

  • KEV（Known Exploited Vulnerabilities Catalog）は、日本語で「既知の悪用された脆弱性カタログ」と訳されます。米国CISA（Cybersecurity & Infrastructure Security Agency）が管理・提供する、実際に攻撃者によって悪用されたことが確認された脆弱性のデータベースです。出典：CISA KEVカタログ

一般的な脆弱性データベース（CVEなど）との最も大きな違いは、「悪用される可能性」ではなく「実際に悪用された」という事実に基づいている点です。

分かりやすく言えば、CVE（公開され、識別番号が付けられた脆弱性の情報）という大海原の中から、実際に野外（in the wild）で攻撃に使用されたことが確認された脆弱性を選び出したリストがKEVなのです。

CVSS・EPSSとの違い

脆弱性の優先順位付けでは、KEVのほかにCVSSやEPSS（Exploit Prediction Scoring System）も使われます。KEVは悪用に関する確認情報、EPSSは今後の悪用可能性の推定、CVSSは技術的な深刻度という違いがあります。

3つは役割の異なる情報で、どれか1つで他を置き換えるものではありません。KEVに載った問題を、低いEPSSスコアだけを理由に後回しにしないようにします。EPSSの読み方も併せて確認してください。

KEVとKEVカタログの違い

実務上、この2つの用語はほぼ同義で使われますが、厳密には以下の違いがあります。

  • KEV：実際に悪用された個々の脆弱性そのものを指す用語
  • KEVカタログ：それらの脆弱性をデータベース化し、体系的に管理しているリストやシステム全体

本記事では主に「KEV」という表記を使用しますが、「KEVカタログ」も同じ意味として扱います。

KEVに登録される3つの厳格な基準

KEVへの登録は誰でも自由にできるわけではありません。CISAが定める3つの条件を全て満たす必要があります。

基準1：CVE IDが割り当てられていること

CVE（Common Vulnerabilities and Exposures）とは、共通脆弱性識別子のことです。公開された脆弱性に「CVE-2024-12345」のような一意の番号が割り当てられ、情報共有の基盤となっています。

KEVに登録されるには、まずこのCVE番号が必要です。つまり、公に認知され、体系的に管理されている脆弱性であることが前提条件となります。

基準2：実際に悪用されている信頼できる証拠があること

これがKEVの最も重要な基準です。単なる「悪用の可能性」や「理論上の脆弱性」ではなく、実際の攻撃活動が確認されている必要があります。

証拠として認められるもの：

  • 実システムへの攻撃成功例の報告
  • ハニーポット（囮システム）での攻撃観測
  • セキュリティベンダーやCISA自身が確認した攻撃活動
  • 信頼できる脅威インテリジェンスソースからの報告

⚠️ 除外されるもの：

  • 単なるスキャン行為（攻撃者が脆弱性の存在を確認しただけ）
  • PoC（Proof of Concept：概念実証コード）の公開
  • 理論上の悪用可能性の指摘

基準3：明確な是正ガイダンスが公開されていること

脆弱性を発見しただけでなく、その対処方法が明確に示されている必要があります。

具体的には：

  • ベンダー提供のセキュリティパッチ
  • 緩和策や回避策（パッチが提供されない場合）
  • サポート終了製品の場合の代替手段

対処方法が存在しない、または不明確な脆弱性はKEVに登録されません。これにより、「分かっているのに何もできない」という状況を避けています。

掲載の有無だけで安全を判断しない

KEVは、3つの基準を満たすことをCISAが確認した脆弱性の一覧です。そのため、カタログに載っていないことは、悪用がないことや対応不要であることの証明にはなりません。たとえば基準3のとおり、明確な対処方法が公開されていない脆弱性は、悪用されていても掲載されません。

一方、掲載されたCVEが自社の製品・バージョンに関係する場合は、公開範囲や対策状況を速やかに確認します。

なぜ今、KEVが不可欠なのか？5つの背景

背景1：脆弱性の増加と対応リソースの限界

新たに公開される脆弱性は毎年多数にのぼります。冒頭で紹介した調査でも、2021年に報告された脆弱性は20,130件に達していました。

一方で、セキュリティ人材や対応に充てられる時間には限りがあります。全ての脆弱性に同じ速さで対応することは現実的ではなく、優先順位付けが必須となっています。

KEVは、この困難な状況下で「どの脆弱性を優先すべきか」を判断するための有力な手がかりになります。

背景2：実際の悪用スピードの速さ

KEVに登録される脆弱性の中には、次のようなものがあります。

  • 脆弱性が公表される前から悪用されていたもの（ゼロデイ攻撃）
  • 公表から短期間のうちに悪用が確認されたもの

悪用が確認された脆弱性は、すでに攻撃者が使える状態にあります。「後で対処しよう」という判断は、被害に直結するリスクを高めます。自社で使用している製品がKEVに該当する場合は、緊急性の高い問題として扱う必要があります。

背景3：米国連邦政府機関への義務化と民間企業への影響

2021年11月、CISAはBOD 22-01（Binding Operational Directive 22-01）という拘束力のある運用指令を発出しました。これにより、米国連邦政府機関には以下の対応が義務づけられました。

  • KEVカタログの継続的な監視
  • KEVに登録された脆弱性への期限内の対応（多くの場合、2週間以内）

2026年6月には、BOD 22-01に代わる指令としてBOD 26-04（Prioritizing Security Updates Based on Risk）が発出されました。新しい指令では、KEVへの掲載を判断要素の一つとし、リスクに応じた期限で修正する方式に改められています。

民間企業には法的義務はありませんが、以下の理由から無関係ではいられません。

日本企業も注目すべき理由：

  • グローバルサプライチェーンの一部として、取引先から対応状況を問われる可能性
  • 米国政府機関が採用している基準として、優先順位付けの参考になること
  • 監査やコンプライアンス対応で、脆弱性管理の判断根拠を説明しやすいこと

背景4：ランサムウェア攻撃との関係

KEVカタログには「knownRansomwareCampaignUse」というフィールドが存在します。このフィールドでは、その脆弱性がランサムウェアキャンペーンで悪用されたことが把握されているかどうかが示されます。ランサムウェア対策として優先すべき脆弱性を絞り込む際の手がかりになります。

ランサムウェア攻撃では、既知の脆弱性を悪用した初期侵入が手口の一つになります。インターネットに公開された機器やサービスにKEV該当の脆弱性が残っていると、攻撃の入口になりかねません。KEVを優先的に対応することは、ランサムウェア対策の基本的な取り組みの一つとなるのです。

なお、このフィールドでランサムウェアでの悪用が示されていないことは、ランサムウェアに使われていないことの証明にはなりません。

背景5：コンプライアンスとリスク管理の観点

監査時に「なぜこの脆弱性には対応しなかったのか」と問われた際、KEVへの掲載の有無は説明根拠の一つになります。

  • KEVに登録され、自社環境に該当する脆弱性：最優先で対応すべき（対応しなかった場合は、理由と代替策について明確な説明責任）
  • KEVに未登録の脆弱性：CVSSやEPSS、資産の重要度などを踏まえたリスク評価に基づく合理的判断の範囲

取締役会への報告材料としても、KEVは客観的で分かりやすい指標となります。

KEVカタログの具体的な活用方法

KEVカタログへのアクセス方法

KEVカタログは誰でも無料でアクセスできます。

公式URL：
https://www.cisa.gov/known-exploited-vulnerabilities-catalog

3つのアクセス方法：

  1. Webブラウザでの閲覧
    • 最も手軽な方法
    • 検索やフィルタリングが可能
    • 最新の掲載内容を確認
  2. CSV形式のダウンロード
    • Excelなどで独自の分析が可能
    • 既存のツールへのインポート
    • オフライン環境での参照
  3. JSON形式のダウンロード
    • 自動化ツールとの連携
    • プログラムによる処理
    • システムへの組み込み

更新通知の受信：
CISAのWebサイトでメールサブスクリプションに登録すると、KEVに新たな脆弱性が追加された際に通知を受け取れます。

KEVを活用した脆弱性管理の実践手順

ステップ1：資産とソフトウェアインベントリの整備

KEVと照合する前提として、自社が使用しているソフトウェアとシステムを把握する必要があります。「何を守るべきか」が分からなければ、KEVとの照合もできません。

CVE番号だけでは修正先を特定できないため、製品名、バージョン、設置先、保守担当を対応付けておきます。OSやミドルウェアの台帳に加え、アプリケーションに組み込まれたライブラリを確認する際にはSBOM（Software Bill of Materials）が役立ちます。インターネットに公開している資産の把握には、ASM（Attack Surface Management）による外部からの探索も有効です。

ステップ2：KEVカタログとの照合

自社の脆弱性スキャン結果やシステムインベントリとKEVカタログを照合し、使用している製品に関係するCVEがKEVに登録されているかを確認します。

ベンダーによっては修正を既存バージョンへ取り込むこともあるため、単純なバージョン比較だけで影響を確定せず、ベンダーのセキュリティアドバイザリやパッケージ情報を確認します。調査結果は「影響あり」「影響なし」「未確認」に分けると、調査中の問題が埋もれにくくなります。

自社環境に該当するCVEが見つかった場合は、最優先で対応が必要です。

ステップ3：影響範囲の特定

該当脆弱性が存在するシステムやアプリケーションを洗い出します。

  • どのサーバーに影響があるか
  • インターネットに公開されているか
  • 重要な業務システムか
  • ビジネスへの影響度はどの程度か

この段階で、SBOMがあると、依存関係を含めた影響範囲を特定しやすくなります。

ステップ4：修正措置の実施

優先順位に基づいて対応：

  1. パッチ適用：ベンダーが提供するセキュリティパッチを適用
  2. 緩和策の実装：即座のパッチ適用が困難な場合の一時的対策
  3. 該当システムの隔離：どうしても対応が間に合わない場合の最終手段

すぐに更新できない場合は、ベンダーが示す緩和策や公開範囲の制限などが有効かを検討し、変更による業務影響も評価します。暫定措置には見直し日を設けます。

ステップ5：修正結果の検証と記録

修正後は、対象バージョンや設定が変わったことを確かめて完了を記録します。スキャン結果だけで判断できない場合は、設定・パッケージ・ログなども確認します。

侵害の兆候があるときは、パッチ適用だけで完了にせず、インシデント対応につなげます。

ステップ6：継続的なモニタリング

KEVには随時新しい脆弱性が追加されます。一度確認して終わりではなく、継続的な監視体制が必要です。

新しい掲載を確認する担当、資産照合の方法、対応状況を共有する場所を決めておきます。JSON形式のデータやメール通知を使って確認を自動化すると、新たにKEVに追加された脆弱性に気づきやすくなります。一度の棚卸しで終わらず、資産や構成が変わった際にも照合し直します。

KEVを活用した対応優先順位付けフレームワーク

全ての脆弱性を同時に対処することは現実的ではありません。以下のような区分で優先順位を付けましょう。各区分の対応期限は、組織の体制や資産の重要度に合わせてあらかじめ決めておきます。

優先度

条件

対応の考え方

最優先

KEV登録あり × 自社環境に存在 × インターネット公開

即座に対応

高優先

KEV登録あり × 自社環境に存在 × 内部ネットワークのみ

早急に対応

中優先

CVSS高/重大 × KEV未登録 × EPSS高スコア

計画的に対応

低優先

CVSS中以下 × KEV未登録

通常の脆弱性管理プロセスで対応

KEVに登録されている脆弱性は、EPSSスコアが低くても後回しにしません。また、KEV未登録でも侵害の兆候がある場合や、重要な資産に関わる場合は優先度を引き上げます。このフレームワークを基準に、限られたリソースを効果的に配分できます。

KEV対応における実務上の課題

一方で、KEVを活用した脆弱性管理を実践する上では、以下のような課題に直面することがあります。

  • 資産の可視化が不十分：KEVとの照合を行う前提として、自組織が使用している全てのシステム、ソフトウェア、デバイスを正確に把握できていないケースが多く見られます。特にクラウドサービスなどの利用拡大により、IT部門が把握していない「シャドーIT」が存在する場合、KEV該当資産の特定自体が困難となります。
  • 対応リソースの不足：KEVに登録された脆弱性には早期の対応が求められますが、セキュリティ担当者の人員不足や技術的なスキルギャップにより、迅速な対応が困難な組織も少なくありません。また、対応の優先順位判断や影響範囲の調査にも相応のリソースが必要です。
  • 業務影響との調整：ミッションクリティカルな業務システムにパッチを適用する際は、システム停止による業務への影響を最小限に抑える必要があり、変更管理プロセスとの調整や、適切なメンテナンスウィンドウの確保が課題となります。
  • 継続的な監視体制の構築：KEVは随時更新されるため、手動での確認では対応が後手に回るリスクがあります。SBOM（Software Bill of Materials）管理と組み合わせた監視・通知の仕組み、およびインシデント対応フローの整備が欠かせません。

これらの課題を解決するためには、資産管理、脆弱性診断、対応の優先順位付け、そして継続的なモニタリングを組み合わせて実施できる体制とツールが不可欠です。

まとめ

CISA KEVカタログは、実際に悪用が確認された脆弱性を掲載する、脆弱性管理の重要な判断材料です。CVSSスコアだけに頼った従来の優先順位付けに「実際に攻撃で使われているか」という情報を加え、本当に危険な脆弱性に焦点を当てることで、限られたリソースを有効に活用できます。

KEV活用のメリット：

  1. 実際に悪用されている脆弱性を優先的に対処できる
  2. 限られたセキュリティリソースを効果的に配分できる
  3. ランサムウェアなどの実際の攻撃に使われている脆弱性への対策を優先できる
  4. 監査やコンプライアンス対応で明確な説明根拠となる

KEVへの対応は、現代の脆弱性管理において欠かせない取り組みです。ただし、KEVに載っていないことは安全の証明ではありません。KEVを適切に運用するためには、資産の把握、ソフトウェア構成の管理、脆弱性診断などを組み合わせ、包括的なアプローチで管理していくことが必要です。

公開資産の把握にはSecurify ASM、ソフトウェア構成の収集と関連する脆弱性の確認にはSecurify SBOMをご覧ください。Securify ASMはドメイン・IP・クラウドから公開資産を発見し、Securify SBOMはリポジトリやコンテナイメージからコンポーネントとバージョンを抽出して、脆弱性情報との照合で問題のあるコンポーネントを特定します。ご興味のある方はぜひお問い合わせください。

まとめの説明画像

参考文献

関連記事

Get Started

WebサイトやAPIの脆弱性を継続診断し、修正後の確認にも活用できます。

ご利用規模・診断頻度に合わせて最適なプランをご提案します。

脆弱性診断のデモを相談するサービス資料を受け取る脆弱性診断の料金を見る
脆弱性診断の詳細を見る脆弱性診断の比較ポイントを見る

WebサイトやAPIの脆弱性を継続診断し、修正後の確認にも活用できます。

脆弱性診断のデモを相談するサービス資料を受け取る脆弱性診断の料金を見る