CISA KEVとは
（“悪用中”の実務的判断材料）

KEVで何が分かるのか

KEVの最大の価値は、脆弱性の深刻度ではなく、“いま現実に狙われているか” を見る判断材料になることです。

CISAは、組織が KEV Catalog を脆弱性管理の優先順位付けフレームワーク（prioritization framework）への入力として使うべきだと説明しており、すべての組織に対して KEV を監視し、掲載された脆弱性の修正を優先するよう強く推奨しています。

また、KEV Catalog は CSV、JSON、JSON Schema でも提供されており、台帳管理や自動化システムに組み込みやすい形になっています。サプライヤー実務においては、OEMからの照会対応や日次/週次のトリアージ業務で “優先度を一段上げる根拠” として非常に使いやすい指標です。

CVSS・EPSSとの違い

ここは非常によく混同されるので、分けて理解すると運用が劇的に楽になります。

つまり、KEV は “予測” ではなく “確認済み” の事実情報です。
CISAのアラートでも、KEVへの追加は evidence of active exploitation（実際の悪用の証拠） に基づくと明確に規定されています。

サプライヤー実務での使いどころ

サプライヤー実務において、KEV は「影響あり/なし」を直接決定づけるものではありません。使いどころは、優先度を上げる判断材料 としての活用です。

たとえば、対象版数や到達性を詳しく確認する前の段階であっても、KEVに掲載されている脆弱性であれば「後回しにしてはいけない」という強力な理由になります。
逆に言えば、KEVに載っている ＝ 自社に必ず影響する わけではありません。 自社製品にそもそもそのコンポーネントが搭載されているか、外部から攻撃が届く経路があるか、成立条件が揃うかといった要素は、SBOMや構成表を用いたトリアージプロセスで別途確認する必要があります。

よくある誤解

• 誤解1：KEVに無いから安全である

  違います。 KEVは「悪用が確認されたもの」の一覧であって、載っていない脆弱性が安全だという意味ではありません。CISAも、KEVはあくまで優先度付けの入力の1つだと位置づけています。

• 誤解2：KEVに載ったら必ず全社で緊急対応が必要

  違います。 KEV掲載は優先度を大きく上げる材料ですが、最終判断には「対象版数・到達性・前提条件」の確認が必要です。自社製品に非搭載（not_affected）であれば、緊急修正の対象にはなりません。これは KEV の問題ではなく、トリアージによる影響判断の問題です。

• 誤解3：Due Date は民間企業にも義務がある

  違います。 CISA の説明では、BOD 22-01 に基づく remediation due date（修正期限）は FCEB agencies（米国連邦政府の対象機関） に適用されるものです。民間企業にそのまま法的義務がかかるわけではありませんが、CISAは民間も KEV を優先修正すべきだと強く推奨しています。

---

FAQ：CISA KEVとは