CISA KEV：已知遭利用漏洞（Known Exploited Vulnerabilities）目錄

什麼是 CISA KEV 目錄？

Known Exploited Vulnerabilities（KEV）目錄由美國網路安全暨基礎設施安全局（CISA）維護。CISA 稱其為已在真實環境中遭利用之漏洞的權威來源，並強烈建議所有組織優先修補這些漏洞。

CISA 於 2021 年 11 月隨具約束力作業指令（Binding Operational Directive，BOD）22-01 建立此目錄。截至 2026 年 9 月 24 日的目錄版本，共收錄 1,723 個漏洞。這只占所有已公開 CVE 的極小部分，而這正是它有用的原因：KEV 項目不是預測，也不是嚴重度評等，而是遭利用的紀錄。

漏洞如何被列入

漏洞符合以下三項條件時，CISA 就會將其列入：

1. 具有 CVE ID。
2. 遭到積極利用，且有可靠證據顯示它曾經或正在遭到利用。
3. 有明確的修補指引，也就是受影響組織可採取的明確行動，例如廠商更新。

第三項條件在實務上很重要：一個漏洞可能在遭利用一段時間後才出現在 KEV 中，因為當時還沒有可參照的修正。任何人都可以透過 CISA KEV 頁面上的表單提名漏洞。

每筆 KEV 項目包含的內容

欄位	內容
cveID	CVE 識別碼
vendorProject、product	受影響軟體的製造者，以及是哪一項產品
vulnerabilityName、shortDescription	名稱與簡短說明
dateAdded、dueDate	CISA 列入的日期，以及美國聯邦機構的修補期限
requiredAction	應採取的行動，通常是套用廠商的更新或緩解措施，或停止使用
knownRansomwareCampaignUse	若曾用於勒索軟體攻擊活動則為「Known」，否則為「Unknown」
forensicTriage	若 BOD 26-04 要求對其進行鑑識分級研判，則為「Yes」
notes、cwes	參考資料與弱點類型

目前有 361 筆項目被標示為曾用於勒索軟體攻擊活動。如果您必須在 KEV 內部排定順序，這些應優先處理。

BOD 26-04：聯邦機構的 KEV 期限

對美國聯邦民政行政部門機構而言，KEV 不只是建議。2026 年 6 月 10 日發布的具約束力作業指令 26-04，規定了它們必須多快完成修補。它廢止了 BOD 22-01（該指令對多數 KEV 項目給予兩週期限，對 2021 年以前指派的 CVE 給予六個月）以及 BOD 19-02。將漏洞列入 KEV 的條件則維持不變。

BOD 26-04 參考 CISA 的 SSVC 決策模型，依據四個問題訂定各項期限：

• 是否公開暴露：該資產能否從公共網路連線？
• KEV 狀態：該漏洞是否在目錄中？
• 利用自動化：攻擊者能否自動化利用？
• 技術影響：遭利用後會造成部分或完全的控制權？

依答案不同，期限從 3 天（並需進行鑑識分級研判，確認系統是否已遭入侵）到在下一次系統升級時修正不等。除非合約另有規定，此指令不適用於聯邦政府以外的企業。即便如此，它仍是您制定自身政策時實用的參考基準。

軟體開發者如何運用 KEV

多數 KEV 項目出現在大型廠商的產品中：光是 Microsoft 就占 388 筆，其次是 Cisco、Apple、Adobe 與 Google。開源軟體也會出現，而且出現時往往位於他人的產品之中。Log4Shell（CVE-2021-44228）就是大家都記得的例子。

建置管線也無法置身事外。遭入侵的 GitHub Actions tj-actions/changed-files（CVE-2025-30066）與 reviewdog/action-setup（CVE-2025-30154）都已列入目錄：已知遭利用的漏洞不只可能存在於產品中，也可能存在於建置產品的工作流程裡。

1. 將 KEV 與您實際交付的內容比對，而不是與儲存庫宣告的內容比對。透過遞移相依引入、或由建置腳本下載的有漏洞函式庫，仍然存在於產品中。
2. 將比對結果視為資安事件，而不是待辦事項。修正它，或加以緩解並記錄原因。
3. 確認您的暴露期間。哪些版本交付了有漏洞的版本？從何時開始？這正是客戶會問的問題。
4. 留意通報時限。依據 EU Cyber Resilience Act（CRA），產品中遭積極利用的漏洞會讓製造商負有 24 小時早期預警的義務。
5. 其餘的漏洞則以 EPSS 與 CVSS 排序。漏洞優先排序說明了具體方法。

如何取得 KEV 資料

• CISA：目錄頁面，以及 CSV、JSON 檔與 JSON schema。
• GitHub：cisagov/kev-data 鏡像這些資料檔，並隨目錄更新。
• 電子郵件：CISA 提供目錄更新的訂閱服務。
• 您的工具：許多掃描工具與漏洞管理平台都會標示 KEV 項目，包括 Grype、Tenable、Qualys 與 Rapid7。

CRACI 如何協助您

KEV 告訴您哪些漏洞遭到利用，CRACI 則告訴您它們在哪裡。CRACI 執行您的 GitHub Actions 作業，記錄每個作業實際擷取的套件，包括遞移相依套件、快取的套件，以及任何 lockfile 都沒有列出的隱藏相依套件，並持續重新評估受監控的 SBOM。

• 哪些建置受到影響。建置歷史會顯示過去哪些建置包含有漏洞的相依套件（無論直接或遞移），讓您掌握暴露期間。
• 由誰修正。資安團隊分級研判各項發現，並將每一項轉交給負責修正的團隊。
• 避免再次交付。政策關卡可以封鎖含有特定 CVE 的建置。
• 完成通報。對於 CRA 規範下遭積極利用的漏洞，CRACI 會準備通報內容，再由製造商的人員透過 Single Reporting Platform 提交。

CISA KEV：常見問題

什麼是 CISA KEV？

Known Exploited Vulnerabilities（KEV）目錄是 CISA 整理的清單，列出已在真實環境中遭利用的漏洞。CISA 稱其為遭利用漏洞的權威來源，並鼓勵所有組織優先修補這些漏洞。

KEV 目錄收錄了多少個漏洞？

截至 2026 年 9 月 24 日的目錄版本共 1,723 個，而已公開的 CVE 有數十萬筆。其中 361 個被標示為已知曾用於勒索軟體攻擊活動。

漏洞要符合什麼條件才會列入 KEV？

三項條件：具有 CVE ID、有可靠證據顯示它曾經或正在遭到利用，以及有明確的修補指引，例如廠商更新。

民間企業必須遵守 KEV 的期限嗎？

不需要。這些期限依據具約束力作業指令 26-04，僅約束美國聯邦民政行政部門機構。其他組織可以將此目錄作為排定優先順序的依據，許多客戶與稽核人員也期待您這麼做。

BOD 22-01 由什麼取代？

2026 年 6 月 10 日發布的 BOD 26-04 廢止了 BOD 22-01 與 BOD 19-02。它不再對 KEV 項目採用固定的兩週期限，而是依據 KEV 狀態、公開暴露程度、利用能否自動化以及技術影響，訂定從 3 天到下一次系統升級不等的期限。

KEV 與 EPSS 有什麼不同？

KEV 記錄的是已經遭到利用的漏洞。EPSS 則估算任一已公開 CVE 在未來 30 天內遭到利用的機率。請先以 KEV 處理，再以 EPSS 排序其餘漏洞。