DevOps General Discussion

CISA KEV 目錄：系統管理員實用使用指南

大多數企業團隊對 CISA 已知遭利用弱點目錄的了解方式，就如同他們了解天氣一樣：標題在畫面中捲動（「CISA 新增三個弱點至 KEV 目錄」），有人轉發，然後大家點頭。這浪費了弱點管理中最具操作實用性的單一清單。KEV 規模小、可機讀、近乎每日更新，而且清單中的每一筆都有您的掃描器輸出無法提供的特性：真正的攻擊者已經在真正的網路上利用過它。

Dev.to · Jul 31, 2026

CISA KEV catalog: a working sysadmin's guide to actually using it

這是一份關於目錄本身的指南：它承諾什麼、不承諾什麼、資料饋送的結構如何、如何將項目對應到您自己的環境而不自欺欺人，以及如何將它與 EPSS 和廠商通告結合，制定出可辯護的修補順序規則。本文所有內容皆已根據 2026 年 7 月底的即時饋送與 CISA 官方頁面驗證。

KEV 是什麼，以及不是什麼

CISA 將 KEV 描述為已在野外遭利用之弱點的權威來源。收錄需通過三項條件，且必須全部成立：

已指派 CVE ID。
有可靠證據顯示已在野外遭主動利用。
有明確的修補措施，例如廠商提供的更新。

將這些條件視為排除條件，目錄的真實輪廓就會浮現。尚未指派 CVE？不在 KEV，即使利用行為猖獗。已回報利用但未達到 CISA 的證據門檻？不在 KEV。已被利用但無修補或緩解措施？不在 KEV。這個目錄是經過篩選的下限，而非普查。截至 2026.07.29 版本，饋送包含 1,656 筆項目，而生態系每年發布數萬筆 CVE。未出現在 KEV 並非安全的證據；出現在 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 結構描述：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 饋送，並檢查您的韌體版本是否有合規偏移——我在另一篇文章中介紹了該建置：Build a 5-minute morning security brief。本文將聚焦於目錄本身。

將 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 只回答一個問題：這是否正在被利用？它沒有說明其他所有弱點被利用的可能性，也沒有說明利用對您而言有多嚴重。因此請依此順序結合三個訊號：

KEV 成員資格是閘門，而不是分數。 任何出現在 KEV 且存在於您環境中的項目，都要排到隊伍最前面，沒有例外。在該集合內，依 dueDate 排序，並將 knownRansomwareCampaignUse: "Known" 的項目排在最前。暴露程度決定日曆：對於網際網路面向的資產，請將 CISA 的到期日視為您的到期日；對於僅內部資產，下一個排定的維護時段通常是可辯護的。這正是 BOD 26-04 暴露變數的精神。
EPSS 為 KEV 未涵蓋的項目排序。 FIRST 的Exploit Prediction Scoring System 估計 CVE 在未來 30 天內被利用的機率，而免費 API 每次只需對一個 CVE 發出一個 GET 請求。它之所以能補足 KEV，正是因為它在 KEV 是確認性的地方提供預測性。不過要了解其在接縫處的盲點：全新的 KEV 項目通常還沒有有意義的 EPSS 分數。CVE-2026-20316 進入目錄的當天，EPSS 根本沒有它的分數，而 2008 年版的 Cisco IOS 項目則得到 0.33，高於 98% 的 CVE。KEV 第一，EPSS 第二，不只是一句口號；這個順序是承重結構。
廠商通告決定您實際要怎麼做。 每一筆 KEV 項目都會在 notes 欄位連結其通告。通告會告訴您修正版本、是否存在因應措施，以及您的特定組態是否受影響。在 Cisco 環境中，KEV 告訴您 FMC 正遭受主動攻擊；只有 Cisco 通告能告訴您您的版本是否已有修正建置，以及在等待維護時段時的緩解措施是什麼。

一行政策：暴露資產出現 KEV 比對，代表依 CISA 的時程立即修補；內部資產出現 KEV 比對，代表下一個維護時段，勒索軟體標記優先；無 KEV 比對，則依 EPSS 與嚴重性排序，並以正常步調處理，以廠商通告作為修正本身的真實來源。

誠實的限制

KEV 是弱點管理中最好的免費訊號，但它仍會以特定、可預測的方式讓您失望。

它設計上就會落後。 必須先有在野利用的證據，且達到 CISA 的門檻，項目才會出現。對於在修補程式存在前就被利用的零時差弱點，條件三會阻擋收錄，直到修補程式推出，而到項目出現時，您可能已經落後攻擊者好幾天。KEV 永遠無法成為您皇冠級產品的早期預警系統；廠商 PSIRT 饋送與緊急通告才掌握那段時間。它在另一個方向也會落後：2026 年 7 月新增的 Cisco IOS 項目是 CVE-2008-4128，一個十八年前的弱點。利用證據何時出現，就何時出現。

它不帶嚴重性或適用性脈絡。 項目沒有分數，到期日反映的是 CISA 對聯邦網路的風險模型，而不是您的暴露程度。兩個到期日相同的項目，對您而言可能有截然不同的意義。目錄無法知道您是否有該產品、它是否可達，或是否有補償性控制已阻擋利用路徑。它是優先順序的輸入，而不是優先順序本身。

有些項目是累贅，偶爾還有一個是完全錯誤的。 只會成長的目錄會累積早已 EOL 的產品項目；如果那些 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，這是一份免費的每週五分鐘簡報，內容關於哪些企業修補不能等——Cisco、Windows Server、VMware。訂閱：https://the-patch-window.beehiiv.com

Read the original source Next news

#Security