了解常見漏洞與曝險（CVE）

什麼是常見漏洞與曝險？

當您在凌晨 3 點發現漏洞時，CVE 識別碼可確保您的安全工具、供應商公告與威脅情報摘要全都使用同一個標準化名稱來指稱相同漏洞。這可在您只有數小時而非數天可回應時，消除混淆。

MITRE Corporation（由 DHS 指定）維護 CVE，作為您在回報漏洞時安全工具所參照的字典。CVE 標準化提供單一識別碼（CVE-YYYY-NNNN 格式），讓您能在發現、評估、排序優先順序、修補與驗證工作流程中進行一致追蹤。

根據 MITRE 的 CWE Top 25 Methodology，您在 2025 年需處理包含 39,450 筆漏洞記錄的系統。您無法修補所有項目，因此需要標準化識別來有效進行優先排序。

CVE 與 CVSS：有何差異？

CVE 和 CVSS 回答的是不同問題。CVE 告訴您漏洞是什麼。CVSS 告訴您其嚴重程度。

CVE（常見漏洞與曝險） 提供 CVE-YYYY-NNNN 格式的識別碼，其中 YYYY 為指派年份，NNNN 為序號。這可讓您在整個安全堆疊中進行一致追蹤。

CVSS（通用漏洞評分系統） 使用三種不同的指標提供 0.0 到 10.0 的嚴重性分數：

• 基本指標 評估漏洞本身的內在特性
• 時間指標 納入隨時間變化的因素，例如可利用性與修補程式狀態
• 環境指標 評估對您特定環境的情境影響，包括資產關鍵性與既有安全控制

CVE 與 CVSS 結合後，可實現有效的優先排序。您的漏洞掃描器發現 CVE-2021-44228，您的威脅摘要確認其 CVSS 基本分數為 10.0，而您的環境分數則會根據易受攻擊的 Log4j 執行個體是否面向網際網路或處於隔離狀態而調整。這讓您獲得完整視圖，進而推動更快速且更準確的回應決策。

為何 CVE 在資安中很重要

威脅行為者會將漏洞武器化，而您的 漏洞管理流程則致力於處理這些漏洞。CVE 標準化無法消除此時間差，但可避免您浪費數小時辨識工具所標示的是哪個漏洞。您可以更快做出分級處理與回應決策。

若沒有 CVE 標準化，您的掃描器可能會將某漏洞稱為「Remote Code Execution in Apache Log4j」，您的威脅情報摘要可能會提到「Log4Shell」，而您的供應商公告可能會描述為「JNDI Injection Vulnerability」。CVE-2021-44228 消除了這種混淆。一個識別碼，一個漏洞，在您環境中的每一項安全工具之間都能一致追蹤。

根據 ENISA 的 Threat Landscape 2025，漏洞利用占歐洲組織遭入侵事件的 21.3%。隨著威脅行為者將漏洞利用作為企業入侵的初始存取向量，這代表顯著增加。

CISA 的 Known Exploited Vulnerabilities 目錄追蹤 1,484 個漏洞，這些漏洞已確認在真實世界的網路攻擊中遭到主動利用。這些漏洞占所有已知 CVE 的比例不到 1%，但對您的企業構成最高風險。CVE 標準化讓 CISA 能以明確無歧義的識別碼發布此目錄，供您的安全工具立即使用。

CVE 漏洞利用的真實世界影響

2021 年 Colonial Pipeline 的 勒索軟體攻擊展示了當漏洞被武器化時會發生什麼事。攻擊者利用舊版 VPN 漏洞（缺乏多重要素驗證）取得初始存取權，接著部署了 DarkSide ransomware，加密了 5,500 英里的燃料管線基礎設施。根據 DOJ court documents，此次攻擊迫使其全面停止營運六天，造成美國東岸燃料短缺，並使公司支付 440 萬美元贖金，外加數千萬美元的復原成本。

2017 年 Equifax 資料外洩事件是因未修補 CVE-2017-5638（Apache Struts 漏洞）所致，導致 1.47 億名消費者的個人資訊外洩。根據 FTC settlement documents，該事件使 Equifax 至少支付 5.75 億美元和解金，若再加上資安改善與法律費用，總成本超過 14 億美元。該漏洞已公開揭露兩個月且已有修補程式可用，但在 Equifax 的環境中仍未修補。

這些案例凸顯了理解漏洞如何從發現一路進入您的安全儀表板的重要性。這段過程遵循特定的工作流程。

了解常見漏洞與曝險工作流程

CVE 指派工作流程決定了在威脅行為者發動攻擊之前，您能獲得數小時還是數週的預警。漏洞從發現到您的掃描器發現，會經過五個明確階段：

• 發現 發生於研究人員、供應商或您的安全團隊透過 滲透測試、威脅狩獵或 事件回應
• 通報 發生於您將漏洞通報給 CVE Numbering Authority (CNA) 時，也就是涵蓋受影響產品的授權組織
• CVE ID 請求 將流程正式化，因為 CNA 會評估該問題是否符合漏洞資格
• ID 保留 發生於 CNA 為已驗證的漏洞保留 CVE 識別碼時，從而實現協調揭露，讓供應商能在公眾知悉前先行修補
• 發布 在 CNA 發布包含完整漏洞詳細資訊的 CVE 記錄時完成此工作流程，內容包括描述、受影響產品及修補指引

此工作流程取決於管理它的組織。了解由誰指派 CVE 識別碼，有助於您知道應向何處通報漏洞，以及它們會多快獲得標準化追蹤。

誰負責指派與管理 CVE

CVE Numbering Authorities (CNAs) 會在其定義的範圍內指派 CVE 識別碼，全球有數百個 CNA 在運作。CNA 包括供應商組織、開放原始碼專案、CERT 組織以及漏洞獎勵提供者。這種分散式模型使漏洞處理速度比集中式方法更快，且每個 CNA 都維持其特定產品領域的專業知識。

CNA 計畫透過階層式結構運作。最上層由 MITRE 擔任主要 CNA 與計畫管理者，負責制定政策並協調全球網路。Root CNAs 管理特定領域或區域內的 CNA 群組。例如，CISA 擔任關鍵基礎設施部門的 Root CNA，而 Japan CERT Coordination Center (JPCERT/CC) 則協調亞太地區的 CNA。此階層架構可確保標準一致，同時發揮區域專業能力並加快回應時間。

主要科技供應商會作為其自家產品的 CNA。Microsoft、Google、Apple、Cisco 和 Oracle 各自為其軟體與硬體中發現的漏洞指派 CVE 識別碼。當安全研究人員在這些產品中發現漏洞時，他們會直接向供應商的安全團隊通報，由其在開發修補程式的同時處理 CVE 指派。這種整合可加速從發現到修補的時程。

MITRE 建立了您今日使用的基礎架構，並持續協調全球 CNA 網路。MITRE 於 1999 年建立 CVE 清單，制定提交內容的審核流程，並設定漏洞分析標準。該計畫已從由單一組織指派識別碼，發展為橫跨 40 多個國家、由超過 300 個 CNA 組成的全球網路，反映出軟體漏洞範圍的擴大以及對分散式專業知識的需求。

當您發現一項漏洞時，識別正確的 CNA 會決定您的發現多快能獲得 CVE 識別碼。首先，請透過官方 CVE 網站的 CNA 清單，確認受影響的供應商是否以 CNA 身分運作。如果該供應商不是 CNA，請聯絡像 CERT/CC 這樣的協調中心，或透過涵蓋相關領域的 Root CNA 進行通報。對於開放原始碼專案中的漏洞，許多主要專案都設有自己的 CNA，包括 Apache Software Foundation、Linux 核心安全團隊，以及 Python Software Foundation。

CVE 如何被發現與通報

安全團隊透過多種管道發現漏洞，而每種管道都有不同特性，會影響 CVE 多快獲得識別碼並進入您的安全工具。

• 安全研究 是 CVE 發現的最大來源。獨立研究人員、學術機構與供應商安全團隊會對軟體與硬體進行系統化分析，以在攻擊者發現之前識別弱點。這些發現通常遵循負責任揭露實務，讓供應商在公開公告前有時間開發修補程式。
• 漏洞獎勵計畫 會激勵外部研究人員直接向供應商尋找並通報漏洞。主要科技公司營運的獎勵計畫已識別出數千個 CVE。當研究人員透過這些計畫提交發現時，供應商的 CNA 可在開發修補措施的同時立即開始 CVE 指派流程。
• 威脅狩獵與事件回應 經常在主動調查期間揭露漏洞。當您的安全團隊調查可疑活動時，他們可能會發現攻擊者正在利用 先前未知的弱點。這些發現經常導致緊急 CVE 指派與加速揭露時程。
• 供應商測試 在軟體開發期間可於發布前發現漏洞。靜態分析、動態測試與程式碼審查可識別弱點；當這些弱點影響先前已發布的版本，或揭露有助於安全社群時，便會獲得 CVE 識別碼。

當您發現漏洞時，通報流程會遵循既定指引。FIRST.org 的協調揭露框架提供了大多數組織遵循的結構：聯絡供應商或適當的 CNA、提供足以重現問題的技術細節，並就兼顧公共安全與修補時間的揭露時程達成一致。大多數供應商以 90 天為修補目標，但遭到主動利用的重大 漏洞 可能需要更快揭露。

每年發布數千個 CVE，因此辨識哪些漏洞類型帶來最大風險，有助於您排定安全工作的優先順序。

作為 CVE 追蹤的常見漏洞類型

CISA 的 Known Exploited Vulnerabilities 目錄揭示了威脅行為者最常武器化的漏洞類型：

• 越界寫入 (CWE-787) 排名第 1，可透過記憶體損毀實現任意程式碼執行
• 跨網站指令碼 (CWE-79) 排名第 2，攻擊者會將惡意指令碼注入 Web 應用程式，並在受害者瀏覽器中執行
• SQL 注入 (CWE-89) 排名第 3，攻擊者會透過輸入欄位注入惡意SQL 命令 through input fields
• OS 命令注入 (CWE-78) 排名第 5，可在未經驗證的情況下直接取得系統存取權

了解這些常見漏洞模式有助於您辨識 零時差威脅，這些威脅會在 CVE 識別碼指派之前利用類似弱點。

了解存在哪些漏洞類型只是部分全貌。理解攻擊者實際如何利用這些弱點，才能為您的防禦策略提供依據。

攻擊者如何利用 CVE

攻擊者透過數種主要攻擊模式利用由 CVE 追蹤的漏洞。

• 遠端程式碼執行鏈 使用注入與記憶體損毀漏洞。Out-of-bounds Write (CWE-787)、Command Injection (CWE-78) 與 Use After Free (CWE-416) 位居 CISA 的 KEV 目錄前列。
• 驗證繞過 利用薄弱的密碼編譯驗證。CISA 記錄了企業 VPN 產品可透過精心構造的 SAML 訊息繞過 SSO，從而在沒有有效憑證的情況下實現未經授權的存取。
• 命令注入 可在無需驗證的情況下直接造成系統遭入侵。攻擊者透過 Web 表單、API 參數或檔案上傳注入惡意命令。存在漏洞的應用程式會以應用程式權限層級執行這些命令。

這些攻擊模式說明了為何 CVE 追蹤對您的漏洞管理計畫至關重要。

CVE 在漏洞管理中的角色

CVE 識別碼可協助您在發現、評估、排序、修補與驗證工作流程中一致地追蹤漏洞。您的漏洞掃描器會發現缺陷並指派 CVE 識別碼，使其能與 威脅情報 摘要、供應商公告與漏洞利用資料庫建立關聯。將 CISA KEV 目錄與您的資產清冊交叉比對，可識別哪些資產包含正遭積極利用的漏洞。

CVE 標準化可簡化工作流程溝通

CVE 編號作為標準化識別碼，可簡化您整個漏洞管理工作流程中的溝通。當您發現漏洞或收到漏洞通知時，CVE 編號可確保每位團隊成員、安全工具與供應商都以一致的標籤參照同一個問題。這種一致性可減少誤解並加速決策，讓您能有效地排定優先順序並協調修補工作。

這個標準化參照點可與各種安全系統整合。您的威脅情報摘要、漏洞掃描器與修補程式管理解決方案都朝向共同目標一致運作：快速且準確地修補漏洞。當您的 EDR 發現與 CVE-2021-44228 相關的可疑活動時，您的 SIEM 會使用相同的識別碼將其與漏洞掃描資料建立關聯。您的工單系統會在相同參照下追蹤修補進度，而您的合規報告則使用標準化術語記錄回應。

CVE 標準化也可簡化整個組織安全環境中的報告與合規流程。安全評估、稽核報告、董事會簡報與法規申報都參照相同的 CVE 識別碼。您不必花費數小時確認三個不同警示是否指向同一個漏洞，而是能立即在所有系統中辨識出 CVE-2021-44228，並將有限時間專注於實際修補。

跨安全工具協調回應

CVE 識別碼可讓您的安全營運中心有效率地在不同安全工具間排定漏洞優先順序並進行分類處理。當新漏洞出現時，CVE 識別碼會提供一致的參照點。您的漏洞掃描器標記 CVE-2024-12345，您的威脅情報摘要為 CVE-2024-12345 提供利用情境，您的 patch management 系統追蹤 CVE-2024-12345 的部署狀態，而您的工單系統則管理 CVE-2024-12345 的工作流程。

這種標準化可減少協調錯誤並加速決策。有了 CVE 標準化，您可有效分配資源，並確保在整個企業環境中一致地套用修補程式。統一的參照可支援自主工作流程：您的安全協調平台會自動將掃描器發現結果與威脅情報建立關聯、為受影響資產建立工單，並透過單一識別碼追蹤修補進度。

以風險為基礎的優先排序

優先排序需要超越僅依賴 CVSS 的方法。將 EPSS (Exploit Prediction Scoring System) 與 CISA 的 Known Exploited Vulnerabilities 目錄整合，可藉由聚焦於少數代表實際已確認風險的 CVE 來提升效率。

先以 CISA 的 KEV 目錄作為您的即時優先篩選條件。對其餘 Critical/High CVE 套用 EPSS 機率分數。使用 Stakeholder-Specific Vulnerability Categorization (SSVC) 納入組織情境。

NIST Cybersecurity Framework 2.0 將漏洞管理組織為六大功能：Govern、Identify、Protect、Detect、Respond 與 Recover。

雖然 CVE 標準化帶來顯著效益，但此系統也面臨會影響您漏洞管理工作流程的挑戰。

CVE 系統的挑戰與限制

當您的漏洞管理工作流程依賴不完整的 NVD 資料時，就會發生失效。漏洞掃描器發現新的 CVE，但 NVD 回傳 "analysis pending," 迫使您要嘛預設將其視為 Critical（造成警示疲勞），要嘛使用供應商公告與威脅情報摘要進行人工研究。

根據 MITRE 的方法論，您正在處理一個於 2025 年有 39,450 筆漏洞記錄 的系統，而這樣的數量已超過可用分析資源的負荷。

NVD 資料限制與多來源情報需求

National Vulnerability Database 提供有價值的 CVSS 分數與漏洞描述，但若僅依賴 NVD 進行漏洞資料分析與追蹤，將在您的security posture 中造成缺口。NVD 最顯著的限制是缺乏環境情境：CVSS 分數無法反映真實世界中的可利用性，或對您環境的特定影響。若受影響元件執行於沒有網際網路存取的隔離網段中，則被評為 Critical 的漏洞對您的基礎架構可能只構成極低風險。相反地，存在於面向網際網路且處理客戶資料之應用程式中的 Medium 嚴重性漏洞，可能才是您最高優先的風險。

NVD 資料缺乏實際利用狀態的情境資訊。雖然 CVSS Base 分數評估的是理論上的嚴重性，但並不表示威脅行為者是否正在真實攻擊中積極將該漏洞武器化。這項資訊缺口會造成漏洞優先排序錯誤的風險：您的團隊可能花上數週修補理論上的 Critical 嚴重性漏洞，卻忽略了攻擊者正在積極利用的 Medium 嚴重性漏洞。

大量的 NVD 積壓進一步加劇了這些挑戰。根據 NIST 的 NVD 計畫更新，由於 2024 年 CVE 提交量增加了 32%，而處理能力仍然受限，積壓情況持續擴大。近期漏洞經常在數週或數月內顯示為「分析待處理」狀態，使安全團隊在遭利用風險最高的早期階段無法取得 CVSS 評分。若未整合其他情報來源，例如供應商公告、威脅情報饋送，以及 CISA 已知遭利用漏洞目錄，組織就有可能出現過度回應或回應不足的風險。

多來源情報方法對於準確的漏洞管理至關重要。您需要供應商公告來取得產品特定情境與修補指引，需要威脅情報摘要來取得利用指標與攻擊者的tactics, techniques, and procedures (TTPs)、CISA 的 KEV 目錄以確認利用狀態，以及 安全研究 社群關係，以便對新興威脅提供早期預警。這種整合式方法可確保您根據實際風險而非僅理論上的嚴重性來排定優先順序。

其他系統挑戰

CVE 計數規則對漏洞追蹤方式造成限制；某些安全弱點可能不會獲得 CVE ID。再加上影響大多數近期 CVE 的大量 NVD 積壓，這些缺口要求安全團隊整合多種情報來源，包括供應商公告、CISA 警示和威脅情報摘要。

分散式 CNA 模型提升了可擴充性，但也帶來一致性挑戰。由於有數百個 CNA 在其定義範圍內運作，CVE 記錄的品質與完整性有所差異。

協調揭露中的時程管理取決於發現者與供應商之間的明確期望，而非僵化的天數要求。安全團隊可藉由了解供應商通常會根據漏洞嚴重性、利用狀態和修補複雜度設定門檻，來預測揭露時程。

儘管存在這些挑戰，經驗證的實務做法仍可協助您在漏洞管理計畫中有效管理 CVE。

管理 CVE 的最佳實務

您應實作結合多種情報來源的風險導向優先排序。先以 CISA 的 Known Exploited Vulnerabilities 目錄作為您的即時優先篩選器。這些 1,484 個漏洞 代表已確認的主動利用，需要最快速的回應。

使用 CISA KEV 進行策略性優先排序

CISA 的 Known Exploited Vulnerabilities 目錄應作為您 修補程式管理 策略的基礎。將您的修補時程直接與利用狀態對齊：列入 KEV 的漏洞需要 2-7 天的回應時限，因為它們代表已確認的主動威脅，而非理論風險。當 CISA 將某個漏洞加入 KEV 目錄時，威脅行為者已經在對像您這樣的組織發動真實世界攻擊時使用它。

使用 KEV 目錄來引導您在即時修補之外的威脅情報工作。定期檢視新加入的 KEV 項目，以了解目前的利用趨勢：威脅行為者正優先利用哪些弱點類型、鎖定哪些產業，以及正在構建哪些攻擊鏈。這些情報可為您的偵測策略提供依據。如果 CISA 將 VPN 產品中的驗證繞過弱點加入 KEV 目錄，即使您已修補特定的 CVE，也應加強監控異常的驗證模式。

KEV 整合可增強您的偵測能力與事件回應整備度。建立專門鎖定 KEV 目錄漏洞利用技術的偵測規則。當 CISA 記錄 CVE-2024-12345 正透過對特定端點發送精心構造的 HTTP 請求而遭到利用時，請建立可找出這些請求模式的網路特徵。設定您的 SIEM，自動將利用嘗試與您的資產清冊進行關聯，識別哪些系統仍然存在弱點並需要緊急修補，以及哪些系統已受到保護。

修補程式管理策略

根據 同儕審查研究，將 EPSS 與 CISA 的 KEV 目錄整合，相較於僅使用 CVSS 的方法，效率提升了 18 倍。根據利用狀態與嚴重性套用修補時程：

整合多種情報來源：供應商公告、自主資料擴增，以及 安全研究 社群關係。

使用可達性分析來降低修復負擔。研究顯示，可達性分析可透過識別存在於程式庫中但在您的特定部署中從未被呼叫的漏洞，顯著減少修復工作量。

維護具備關鍵性分類的詳細資產清冊。追蹤面向網際網路的資產、業務關鍵系統，以及處理敏感資料的系統。建立具明確責任歸屬的文件化修補 SLA。授予修補例外時，請記錄補償控制、持續期間和核准權限。

實作這些最佳實務需要能支援持續漏洞偵測與智慧優先排序的工具。

SentinelOne 如何協助管理 CVE 風險

您需要能持續運作且無需排程掃描的漏洞偵測。 Singularity Vulnerability Management 透過現有的 SentinelOne 端點代理程式部署，並即時監控您的環境。該平台透過您現有的端點涵蓋範圍，在作業系統與應用程式中找出漏洞。

Singularity Platform 可在您的安全環境中提供統一可視性，將漏洞資料與威脅情報摘要相互關聯，自動標示哪些問題需要立即回應。在 MITRE ATT&CK evaluations，SentinelOne 產生的警示比其他端點安全平台少 88%，僅產生 12 則警示，而競爭解決方案則產生 178,000 則。這種減少可消除誤判疲勞，同時確保您的團隊專注於實際威脅。

與 Singularity Platform 生態系統整合，可在 Singularity Endpoint、 Singularity Cloud、 Singularity Identity 以及 Singularity XDR 功能之間實現統一可視性。弱點資料會直接匯入您更廣泛的威脅偵測與回應工作流程，使您能在弱點遭到主動利用時採取協調行動。 Purple AI 根據早期採用者的說法，可將威脅調查速度提升最多 80%，提供自然語言安全分析以增強您團隊的能力。

這種自主式方法消除了傳統掃描中弱點發布與偵測之間的落差。您可獲得持續評估，而無需承擔網路型掃描器的基礎架構負擔、頻寬消耗或排程複雜性。

與 SentinelOne 預約示範，了解 Singularity Vulnerability Management 如何透過持續偵測、自主優先排序與統一威脅回應，降低整個企業的 CVE 風險。

AI-Powered Cybersecurity

Elevate your security posture with real-time detection, machine-speed response, and total visibility of your entire digital environment.

Get a Demo

重點整理

CVE 標準化解決了整個安全堆疊中的溝通問題，確保您的掃描器、威脅情報來源與廠商公告都使用相同的識別碼來引用弱點。每年有 39,450 筆 CVE 記錄，其中不到 1% 代表已確認遭利用，因此有效的優先排序可將可管理的工作負載與警示疲勞區分開來。

請先將團隊有限的時間集中在 CISA 的 KEV 目錄中 1,484 個已確認遭利用的 CVE，然後再對其餘弱點套用 EPSS 機率評分。研究顯示，這種整合式方法相較於僅使用 CVSS 的方法，可帶來 18 倍的效率提升，同時捕捉到更多遭利用的弱點。

NVD 積壓意味著您不能等待完整的擴充資訊。建立多來源情報管線，除了 NVD 資料外，還要擷取廠商公告、CISA 警示與威脅情報來源的資訊，以滿足您對遭主動利用弱點的 2-7 天修補時限。