図：KEVを含む4つの材料から初動の順番を決める考え方。サイト内制作の説明図で、実際の管理画面や特定製品の評価結果ではありません。
記事の概要を読む
KEVとは、CISAが実環境での悪用を確認したCVEの公式カタログです。掲載の3基準、2026年6月発令のBOD 26-04による3日・14日の対応期限、CVSS・EPSS・外部露出・資産重要度を組み合わせた優先順位の決め方を、判断早見表と初動の手順で整理します。
この記事の目次 10項目から選ぶ
この記事の結論：KEVは「すでに悪用された」CVEを示す公式リスト
KEV（Known Exploited Vulnerabilities）とは、米国CISAが実環境での悪用を確認した脆弱性のカタログだ。公式JSONフィードの2026年10月23日版では1,756件が掲載され、2026年に入ってからの追加は272件、ランサムウェアでの利用が「Known（既知）」とされたものは361件ある。
CVSSが「条件がそろったときにどれほど深刻か」を示すのに対し、KEVは「実際に攻撃で使われた」という事実を示す。そのため、脆弱性対応の順番を決めるときの最も強い材料になる。ただしKEVだけで順番は決まらない。この記事の判断基準は次の3点だ。
- 自社に対象の製品・版があるか：なければKEV掲載でも緊急作業は不要。確認した根拠と日時を残す。
- インターネットから到達できるか：KEV該当かつ外部露出なら、24時間以内に封じ込め（公開停止・送信元制限など）を判断する。
- 修正したら終わりではない：悪用済みである以上、侵害の有無の確認までを対応範囲にする。
対象は、脆弱性対応の優先順位を決める情シス・CSIRT・インフラ担当、パッチ計画を説明する管理者、自社製品の依存関係を管理する開発者だ。攻撃手順や悪用コードは扱わない。
KEVの掲載基準：3つを満たしたものだけが載る
CISAは、次の3つをすべて満たした脆弱性だけをKEVへ追加すると説明している。
| 基準 | 内容 | 実務での読み方 |
|---|---|---|
| ① CVE番号がある | CVEが割り当てられている | CVE番号で資産台帳・SBOM・スキャン結果と突き合わせられる |
| ② 悪用の確かな証拠がある | 実環境で実際に悪用された信頼できる証拠がある | 「将来危ないかもしれない」ではなく、すでに攻撃に使われている |
| ③ 明確な修正策がある | ベンダーの更新など、取るべき対処が示されている | 修正版や緩和策があるため、対応しない理由を説明しにくい |
重要なのは、スキャン、脆弱性の調査研究、公開された検証コード（PoC）は「悪用」に数えないと明記されている点だ。つまり「PoCが公開されたのにKEVにない」は珍しくない。KEVに載っていないことは安全の証明ではなく、ベンダーの悪用情報、EPSS、自社の検知とあわせて判断する。
- dateAdded：KEVへ追加された日。悪用が始まった日ではない。
- dueDate：米国連邦政府機関の対応期限。民間企業の義務ではないが、緊急度の目安になる。
- knownRansomwareCampaignUse：ランサムウェアでの利用が既知なら「Known」、確認されていなければ「Unknown」。Unknownは「使われていない」という意味ではない。
- requiredAction：求められる対処。2026年6月以降の追加分はBOD 26-04への準拠が書かれている。
2026年6月からの変化：BOD 26-04で期限が「3日」と「14日」に
KEVの対応期限は、CISAの拘束力のある運用指令（BOD）で決まる。2026年6月10日に発令されたBOD 26-04は、従来のBOD 22-01とBOD 19-02を置き換えた。BOD 26-04では、期限は一律ではなく、次の判断項目の組み合わせで決まる。
| 判断項目 | 確認すること |
|---|---|
| KEVへの掲載 | 対象のCVEがKEVカタログにあるか |
| 外部露出 | 認証なし・信頼できない相手が、インターネットなど公衆網から到達できるか |
| 自動化可能性 | 攻撃の全工程を攻撃者が自動化できるか |
| 技術的影響 | 悪用で対象を部分的に、または完全に制御されるか |
実施ガイダンスのFAQでは、外部に公開された資産にあり、技術的影響が完全な制御で、自動化可能な場合に3日の期限になる例が示されている。期限の起点は、KEVへの追加か、組織が自分の資産で脆弱性を特定したときの早い方だ。インターネットから切り離すと露出の値が変わり、期限が延びることもある。
公式フィードの追加日と期限日を集計すると、変化ははっきり表れている。
| 追加時期 | 件数と適用された指令 | 追加日から期限までの日数 |
|---|---|---|
| 2024年 | 186件・BOD 22-01 | 21日が175件。7日などの短い期限は一部 |
| 2025年 | 245件・BOD 22-01 | 21日が226件。7日が12件、1日が6件 |
| 2026年6月11日以降 | 139件（10月23日まで）・BOD 26-04 | 3日が113件、14日が26件 |
民間企業はこの期限に拘束されない。ただしCISAは、指令に拘束されない組織にも、KEVの脆弱性へ即時に対応する要件を脆弱性管理の計画へ入れるよう強く推奨している。外部公開された資産なら「3日以内に修正か緩和」を、社内の期限を決める際の上限の目安として使える。
修正だけで終わらせない：フォレンジック・トリアージの目安
KEVは「すでに悪用された」脆弱性なので、パッチを当てる前に侵入されていた可能性がある。BOD 26-04の実施ガイダンスは、期限が3日未満となる脆弱性について、侵害の有無を確かめるフォレンジック・トリアージを求め、KEV追加からの時間の目安を示している。
| 段階 | KEV追加からの目安 | 行うこと |
|---|---|---|
| ① 範囲の特定 | 0〜2時間 | 対応チームを招集し、影響する資産とサービスを決め、通常と別の連絡経路を用意する |
| ② 証拠の保全・収集 | 2〜24時間 | 揮発性の情報から先に取得し、収集前に資産を変更しない。収集の記録を残す |
| ③ 修正と安定化 | 2〜24時間 | 証拠を取得した後に修正を適用し、業務を安定させる |
| ④ 封じ込め | 6〜24時間 | 攻撃者に気づかれない方法で、影響する資産を切り離す |
| ⑤ 分析 | 24〜48時間 | 侵害の有無を判断し、侵害の痕跡が他の資産にないか確認する |
| ⑥ エスカレーション判断 | 48〜72時間 | トリアージの報告をまとめ、本格調査へ進むかを決める |
ガイダンスはこれらの時間を推奨の目安としている。自社で同じ体制を組めない場合も、「修正前に証拠を残す」「修正後に痕跡を確認する」という順序は取り入れられる。端末や証跡の扱いは インシデント時の証拠保全 に詳しい。
優先順位は5つの軸を同じ表で見る
CVSSだけでは「実際に攻撃されているか」「自社に対象があるか」が分からない。初動では、次の5軸を1枚のチケットにまとめる。
| 軸 | 何が分かるか | 単独では分からないこと |
|---|---|---|
| KEV | 実環境で悪用された事実 | 自社に対象があるか、侵害されたか |
| CVSS | 技術的な深刻度と条件（最新版はv4.0、2023年11月公開） | 実際の悪用、自社の損失 |
| EPSS | 公開済みCVEが30日以内に悪用される確率（0〜1）とパーセンタイル。毎日更新 | 自社が攻撃される確率、被害額 |
| 外部露出 | インターネット・VPN内・社内限定・検証環境のどこにあるか | 脆弱性の有無そのもの |
| 資産重要度 | 認証基盤・管理画面・顧客データ・開発基盤への近さ | 悪用されるかどうか |
EPSSとKEVの役割の違いは KEVとEPSSの違い、CVEとCVSSの違いは CVEとCVSSの違い で整理している。組織としての「どう動くか」を決める枠組みには SSVC もある。
- 対象なし・社内限定
根拠と確認日時を残して監視へ。次回の棚卸しで再確認する。
- 対象あり・悪用は未確認
露出・権限・修正の可否を確認し、72時間以内の計画に入れる。
- KEV該当・外部露出
24時間以内に封じ込めを判断し、修正と侵害の確認を並行する。
判断早見表：どの条件なら何時間で動くか
次の表は、CyberLens編集部が整理した社内期限の目安だ。BOD 26-04の期限そのものではない。自社の規程・契約・業務への影響を優先して調整する。
| KEV | 外部露出 | 資産 | 初動の目安 | 次の行動 |
|---|---|---|---|---|
| 該当 | あり | 管理画面・認証基盤・境界機器 | 24時間以内に封じ込めを判断 | 公開停止・送信元制限、修正、侵害の痕跡の確認を並行 |
| 該当 | なし（社内・VPN内） | 業務システム | 72時間以内に修正か緩和 | 到達できる経路と利用者を確認し、侵害の痕跡を確認 |
| 非該当・EPSSが高い | あり | 公開サービス | 72時間以内に計画 | ベンダーの悪用情報とKEVの追加を毎日確認 |
| 非該当 | なし | 一般の端末・検証環境 | 7日以内に通常の修正計画 | 例外にする場合は期限と承認者を記録 |
| 対象なし | — | — | 当日中に「対象なし」を記録 | 確認した台帳・版・日時を残して監視へ |
初動の手順：24時間・72時間・7日で分ける
KEVを含む脆弱性対応は「今日中に全部パッチ」では回らない。業務停止の影響、検証時間、メンテナンス枠、委託先との調整があるためだ。初動は時間軸で区切る。
| 時間軸 | やること | 完了の条件 |
|---|---|---|
| 24時間以内 | 対象の有無、外部露出、KEV掲載、暫定遮断の可否を確認する | 影響あり・なし・調査中をチケットで分け、責任者を決める |
| 72時間以内 | 修正の適用、WAF・ACL、認証の強化、監視の強化、ログ確認を進める | 外部露出資産の暫定リスクを下げ、悪用痕跡の有無を記録する |
| 7日以内 | 恒久対応、例外承認、残リスクの説明、台帳更新を終える | 経営・事業部・監査へ判断根拠を説明できる |
確認対象は本番サーバーだけでは足りない。見落とされやすいのは、検証環境や一時的に公開したデモ環境、VPN配下の管理画面、子会社や委託先が運用する同じ製品、開発者が個別に立てたコンテナやVM、放置された古いアプライアンスだ。公開管理画面が関係する場合は 公開管理画面を見つけた時の初動対応 も使う。
ここまでの確認項目は、CVE初動対応チェックリスト にそのまま転記できる形でまとめている。対象の製品が自社にあると分かった時点で、チェックリストを開いて担当と期限を埋めていくと、確認漏れと記録漏れを同時に防げる。
経営・事業部へ説明するときの言い換え
技術指標をそのまま伝えても判断材料になりにくい。事業への影響に言い換えて伝える。
| 技術的な表現 | 事業側に伝える表現 |
|---|---|
| KEVに追加された | 実際に攻撃で使われた弱点として扱う必要がある |
| 外部露出あり | 社外から直接狙えるため、攻撃を受ける可能性が高い |
| CVSS 9.8 | 条件がそろうと、システムを乗っ取られるほどの影響がある |
| 暫定緩和が必要 | 修正の前に入口を閉じて、被害の確率を下げる |
| 例外承認が必要 | すぐ直せない理由と、残る危険を責任者が引き受ける |
CVE番号とスコアだけを送るより、「顧客データに近い公開管理画面で、悪用済みの脆弱性に該当するため、今日中に外部からの到達を止めたい」と伝えた方が、緊急変更の承認が速く進む。
よくある失敗：スコア表だけ、パッチだけ、例外だけ
- スコア表だけで止まる：KEV・CVSS・EPSSの列を並べても、対象資産と外部露出がなければ実務判断にならない。資産台帳と必ず結び付ける。
- パッチだけを対応とみなす：悪用済みの脆弱性では、修正前に侵入された可能性がある。アクセスログ、EDR、認証ログ、変更履歴を確認せずに「更新したので完了」としない。修正後の確認は パッチ適用後の確認 にまとめている。
- 例外を雑に扱う：業務の都合で修正を延期するときも、期限・理由・暫定対策・監視方法・承認者を残す。書き方は セキュリティ例外申請の書き方 を参照する。
次に使うページ
- 今すぐ対応する：CVE初動対応チェックリスト で対象の有無・露出・暫定対策・記録を順に埋める。
- 掲載状況を調べる：CVEトラッカー でCVE番号からKEVの掲載と期限を確認する。
- 深刻度の条件を読む：CVSS計算ツール でベクターを分解し、必要権限やユーザー操作の有無を確かめる。
- 基礎から学ぶ：脆弱性管理の基礎 と CVSS・EPSS・KEVの違いと優先度判断例。
参考情報
資料確認日：2026年10月25日。件数は公式JSONフィード2026年10月23日版の集計値で、カタログは随時更新される。
- CISA: Known Exploited Vulnerabilities Catalog — KEVの公式カタログ。
- CISA: Reducing the Significant Risk of Known Exploited Vulnerabilities — 掲載の3基準と、連邦政府機関以外への推奨。
- CISA: BOD 26-04 Prioritizing Security Updates Based on Risk — 2026年6月10日発令。BOD 22-01・BOD 19-02の置き換えと期限の判断項目。
- CISA: BOD 26-04 Implementation Guidance — 3日期限の条件例とフォレンジック・トリアージの目安。
- CISA: Known Exploited Vulnerabilities JSON feed — 追加日・期限日・ランサムウェア利用の集計元。
- FIRST: Exploit Prediction Scoring System（EPSS） — 30日以内の悪用確率を毎日公開する仕組み。
- FIRST: Common Vulnerability Scoring System（CVSS） — CVSS v4.0の仕様。
国内では、ベンダーの公式アドバイザリ、JPCERT/CC、IPAの注意喚起もあわせて確認する。ニュース記事だけで判断せず、一次情報と自社の資産情報へ戻る。
この記事のよくある質問
KEVとは何ですか？どんな脆弱性が掲載されますか？
KEV（Known Exploited Vulnerabilities）は、CISAが実環境での悪用を確認した脆弱性のカタログです。CVE番号がある、実環境で悪用された確かな証拠がある、ベンダーの更新など明確な修正策がある、の3基準を満たすものだけが掲載されます。2026年10月23日版の掲載数は1,756件です。
KEVの対応期限（dueDate）は何日ですか？
2026年6月10日発令のBOD 26-04以降、期限は外部露出、攻撃の自動化可能性、技術的影響などの判断項目で決まります。2026年6月11日以降に追加された139件では、期限は追加日から3日（113件）または14日（26件）でした。2024〜2025年の追加分は多くが21日でした。
KEVの期限は民間企業にも適用されますか？
期限で拘束されるのは米国の連邦政府機関（FCEB）です。ただしCISAは、指令に拘束されない組織にもKEVの脆弱性へ即時に対応する要件を脆弱性管理の計画へ入れるよう強く推奨しています。自社では、外部露出と資産の重要度に応じた社内期限を決めます。
KEVに載っていない脆弱性は後回しにしてよいですか？
後回しにしてよいとは限りません。KEVは悪用の確かな証拠と修正策がそろったものだけを載せるため、スキャンや公開された検証コードがあるだけでは掲載されません。ベンダーの悪用情報、EPSS、自社のログや検知を合わせて判断します。
