大多数企业团队了解 CISA 已知被利用漏洞目录的方式，就像他们了解天气一样：标题滚动过去（“CISA 将三个漏洞添加到 KEV 目录”），有人转发，大家点头。这浪费了漏洞管理中唯一最有操作价值的列表。KEV 规模小、机器可读、几乎每天更新，并且其中的每个条目都具有您的扫描器输出无法提供的一个属性：真实攻击者已经将其用于真实网络。

本文是关于该目录本身的指南：它承诺什么、不承诺什么、数据源的结构如何、如何将条目映射到您自己的资产而不自欺欺人，以及如何将其与 EPSS 和厂商公告结合，形成可辩护的补丁排序规则。所有内容均根据 2026 年 7 月下旬的实时数据源和 CISA 官方页面进行了验证。

KEV 是什么，以及它不是什么

CISA 将 KEV 描述为已知在野外被利用漏洞的权威来源。条目需满足三项标准，全部必须成立：

  1. 该漏洞已分配 CVE ID。
  2. 有可靠证据表明其在野外被主动利用。
  3. 存在明确的修复措施，例如厂商提供的更新。

将这些标准视为排除条件，目录的真实形态就会显现。没有 CVE？不在 KEV 中，即使利用非常普遍。报告了利用但未达到 CISA 的证据门槛？不在 KEV 中。被主动利用但不存在修复或缓解措施？不在 KEV 中。该目录是一个经过筛选的基准，而不是一份普查。截至 2026.07.29 版本，数据源包含 1,656 个条目，而生态系统每年发布数以万计的 CVE。未出现在 KEV 中并非安全的证据；出现在其中则接近危险的证明。这种不对称性正是整个要点所在，也是为什么正确解读该列表的方式是“这里列出的所有内容都很紧急”，而不是“所有紧急内容都在这里”。

在构建任何内容之前，了解其分布情况也值得注意。Microsoft 以 382 个条目占据主导地位，其次是 Cisco（95 个）、Apple（93 个）、Adobe（80 个）、Google（72 个），然后是过去几年大规模利用的代表性设备厂商：Ivanti（35 个）、Fortinet（29 个）。332 个条目（约五分之一）带有已知勒索软件活动标志。如果您运行的是典型的企业堆栈，该目录中的很大一部分是直接针对您的。

截止日期：BOD 22-01 已废止，其替代方案提高了要求

KEV 是由 2021 年 11 月的 Binding Operational Directive 22-01 创建的，该指令要求美国联邦民用机构在每个列出的 CVE 的截止日期前完成修复。如果您对 KEV 截止日期的认知仍停留在那个时代（“新条目两到三周”），那已经过时了。2026 年 6 月 10 日，CISA 发布了BOD 26-04：基于风险的优先安全更新，它取代并直接废止了 BOD 22-01。KEV 目录本身继续存在，包含标准不变，但截止日期现在由四个变量的风险模型决定：资产的公开暴露程度、KEV 状态、可利用的自动化程度以及技术影响（部分控制与完全控制）。修复时间从三天日历日不等，最坏组合需要强制取证分流；对于不触发任何变量的漏洞，则采用“下次升级时修复”。CISA 的Vulnrichment 计划为每个 CVE 发布了四个变量中的三个的答案；只有资产暴露程度需要您自己确定。

您可以直接从数据源中看到制度变化。自 6 月 10 日以来添加的 39 个条目中，有 34 个带有三天期限，其余为十四天。在旧指令下，三周是常规做法。从我提取数据的当天的一个具体例子：CVE-2026-20316，Cisco Secure Firewall Management Center 中的硬编码密码漏洞，于 2026-07-29 添加，截止日期为 2026-08-01。三天，针对 FMC 漏洞，跨越一个周末。

如果您不是联邦机构，为什么要关心？有两个原因。首先，截止日期是免费的分流：它们编码了 CISA 对利用速度和影响的判断，由拥有您永远看不到的事件数据的人计算得出。当基于该数据的指令说“三天”时，将您自己的面向互联网的 FMC 视为 30 天的工单，是一个您至少应该有意识地做出的选择。其次，KEV 越来越多地出现在有实际约束的地方：网络保险问卷、审计框架和客户安全审查通常会询问您如何跟踪和修复 KEV 列出的漏洞。“我们监控目录并将联邦时间表应用于暴露的资产”是一个清晰、可辩护的答案，实现成本很低。

数据源：跳过网页，消费数据

可浏览的目录页面对人类来说很好，但操作接口是数据源，全部免费且无需身份验证：

  • JSON: https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json
  • CSV: https://www.cisa.gov/sites/default/files/csv/known_exploited_vulnerabilities.csv
  • JSON schema: https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities_schema.json

JSON 文档有一个小信封（title、catalogVersion、dateReleased、count）和一个 vulnerabilities 数组。每个条目包含：cveID、vendorProject、product、vulnerabilityName、dateAdded、shortDescription、requiredAction、dueDate、knownRansomwareCampaignUse（字符串 Known 或 Unknown）、notes（分号分隔的公告 URL）和 cwes。

以下是一个用纯 Node.js（18 或更高版本，无依赖项）编写的最小监视器，它拉取数据源并打印与您的厂商匹配的最近添加内容。我在撰写本文时针对实时数据源运行了这个确切的脚本：

// kev-watch.mjs - Node 18+ (native fetch, top-level await)
const FEED = "https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json";
const KEYWORDS = ["cisco", "vmware", "broadcom", "windows server", "solarwinds"];
const DAYS_BACK = 30;

const res = await fetch(FEED);
if (!res.ok) throw new Error(`KEV feed returned HTTP ${res.status}`);
const { catalogVersion, count, vulnerabilities } = await res.json();

const cutoff = new Date(Date.now() - DAYS_BACK * 86_400_000);
const matches = vulnerabilities.filter((v) => {
  const haystack = `${v.vendorProject} ${v.product}`.toLowerCase();
  const recent = new Date(v.dateAdded) >= cutoff;
  return recent && KEYWORDS.some((k) => haystack.includes(k));
});

console.log(`KEV ${catalogVersion} (${count} total entries)`);
console.log(`${matches.length} matches added in the last ${DAYS_BACK} days:\n`);

for (const v of matches.sort((a, b) => a.dueDate.localeCompare(b.dueDate))) {
  const flag = v.knownRansomwareCampaignUse === "Known" ? "  << RANSOMWARE" : "";
  console.log(`due ${v.dueDate}  ${v.cveID}  ${v.vendorProject}: ${v.product}${flag}`);
}

Enter fullscreen mode Exit fullscreen mode

2026-07-29 的实际输出：

KEV 2026.07.29 (1656 total entries)
2 matches added in the last 30 days:

due 2026-07-16  CVE-2008-4128  Cisco: IOS
due 2026-08-01  CVE-2026-20316  Cisco: Secure Firewall Management Center (FMC)

Enter fullscreen mode Exit fullscreen mode

随意安排该脚本并将其管道传输到电子邮件或聊天中。如果您想要这个想法的更完整版本，一个每天简报，还包括 Microsoft 的 MSRC 数据源并检查您的固件版本是否符合合规性漂移，我在另一篇文章中详细介绍了该构建：构建 5 分钟早晨安全简报。本文将重点放在目录本身。

将 KEV 映射到您的资产：假阴性陷阱

在 vendorProject 和 product 上进行关键字匹配是每个自制 KEV 使用者开始的地方，也是大多数人悄无声息地腐烂的地方。这些字段是人工编写的字符串，而不是受控词汇表，它们至少会以三种方式背叛幼稚的过滤器。

首先，厂商名称会改变。Broadcom 收购前添加的 VMware 条目位于 vendorProject: "VMware" 下；较新的条目，包括 vCenter Server 和 Aria Operations 条目，位于 "Broadcom" 下。仅匹配 vmware 的过滤器会悄无声息地遗漏新的 vCenter KEV。同类问题也适用于重命名的产品：上面的 Cisco FMC 条目在其描述中帮助性地注明“以前称为 Firepower Management Center”，但没有什么能强制未来的条目也这样做。

其次，模糊的产品字符串。像 Zyxel 的 product: "Multiple Products" 这样的条目与任何合理的产品关键字都不匹配。如果您仅根据产品名称进行过滤，这些条目就会消失。

第三，您的库存会说谎。匹配数据源是简单的一半；困难的一半是知道条目中的内容实际上存在于您的网络中，包括 2019 年有人上架但从未进入 CMDB 的设备。

保持方法诚实的实用规则：匹配厂商和产品的串联，而不是仅匹配产品；将收购方名称与遗留厂商名称一起包含（VMware 和 Broadcom、SolarWinds 和 N-able 等）；将您的关键字列表视为配置，当目录让您感到意外时进行审查；每周一次，不论匹配与否，都查看新添加的完整列表，以当前数量（2026 年迄今已添加 172 个），这只需两分钟浏览。关键字过滤器是一个触发器，而不是覆盖保证。如果您需要保证，那就是具有基于 CPE 匹配的扫描器的工作，即使那些扫描器也彼此不同意。

排序规则：KEV，然后是 EPSS，然后是厂商公告

KEV 只回答一个问题：这是否正在被利用？它没有说明其他所有内容被利用的可能性，也没有说明利用对您来说有多糟糕。因此，请按此顺序结合三个信号：

  1. KEV 成员资格是一个门，而不是一个分数。 您资产中存在的任何 KEV 内容都会直接排在队列的最前面。在该集合中，按 dueDate 排序，并将 knownRansomwareCampaignUse: "Known" 的条目放在首位。暴露程度决定日程：对于面向互联网的资产，将 CISA 的截止日期视为您的截止日期；对于仅内部的资产，下一个计划的窗口通常是可辩护的。这正是 BOD 26-04 暴露变量的精神。

  2. EPSS 对 KEV 保持沉默的所有内容进行排名。 FIRST 的漏洞利用预测评分系统估计 CVE 在未来 30 天内被利用的概率，免费 API 每个 CVE 只需要一个 GET 请求。它补充了 KEV，因为它在 KEV 确认的地方具有预测性。不过，要了解其在接缝处的盲点：全新的 KEV 条目通常还没有有意义的 EPSS 分数。在 CVE-2026-20316 进入目录的那一天，EPSS 根本没有它的分数，而 2008 年的 Cisco IOS 条目得分为 0.33，高于 98% 的所有 CVE。KEV 第一，EPSS 第二不仅仅是一个口号；这个顺序是至关重要的。

  3. 厂商公告决定您实际做什么。 每个 KEV 条目都在 notes 字段中链接其公告。公告会告诉您修复版本、是否存在变通方法以及您的特定配置是否受到影响。在 Cisco 环境中，KEV 告诉您 FMC 正在受到攻击；只有 Cisco 公告才能告诉您您的版本列车是否有修复版本，以及在窗口打开之前缓解措施是什么。

作为一行政策：暴露资产上的 KEV 匹配意味着按照 CISA 的时钟立即修补；仅内部的 KEV 匹配意味着下一个窗口，勒索软件标记的优先；无 KEV 匹配意味着按 EPSS 和严重性排名并按正常节奏处理，以厂商公告作为修复本身的真实来源。

诚实的局限性

KEV 是漏洞管理中最好的免费信号，但它仍会在特定、可预测的方式上让您失望。

它按设计滞后。 野外利用的证据必须存在并达到 CISA 的标准，条目才会出现。对于在补丁存在之前就被利用的零日漏洞，标准三会阻止列出，直到修复发布，而到条目出现时，您可能已经落后攻击者几天了。KEV 永远不可能成为您皇冠上的宝石产品的早期预警系统；厂商 PSIRT 数据源和紧急公告拥有那个窗口。它在另一个方向上也滞后：2026 年 7 月添加的那个 Cisco IOS 条目是 CVE-2008-4128，一个十八年的漏洞。利用证据何时到来就何时到来。

它不携带严重性或适用性上下文。 条目没有评分，截止日期反映了 CISA 对联邦网络的风险模型，而不是您的暴露程度。具有相同截止日期的两个条目对您的意义可能大不相同。该目录无法知道您是否拥有该产品、它是否可访问，或者补偿性控制是否已经阻止了利用路径。它是优先级排序的输入，而不是优先级排序本身。

有些条目是死重，极少数只是已失效。 一个只增长的目录会积累已停产多年的产品的条目；如果 EOL 设备仍在架上，这些条目仍然重要，但它们会使幼稚的仪表板变得混乱。而且，虽然证据门槛很高，但并非无懈可击：CISA 在 2023 年 12 月从目录中移除了 CVE-2022-28958，因为 D-Link 的“漏洞”被发现根本不存在，CVE 被拒绝。移除非常罕见，以至于成为新闻，这本身就是一个好兆头，但如果您将数据源镜像到任何下游内容中，请同步删除，而不仅仅是添加。

所有这些都不是反对该目录的论据。它反对的是将其视为完整的风险图景，而不是它实际的样子：一个简短、高置信度的已证实攻击者行为列表，几乎每天刷新，格式是系统管理员可以用三十行代码消费的。大多数组织甚至没有做到这一点。成为做到这一点的那一个。

Adam Lewandowski 是一名网络和安全工程师（CompTIA Security+、CCNA、VMware VCP-DCV），从事 Cisco FTD/FMC/ISE、Windows Server、MECM 和 VMware 环境的工作。 在 LinkedIn 上联系。

我撰写 The Patch Window，这是一份免费的 5 分钟每周简报，内容关于哪些企业补丁不能等待 - Cisco、Windows Server、VMware。 订阅：https://the-patch-window.beehiiv.com