過去二十年來，NVD（國家漏洞資料庫）一直是漏洞管理的事實上的基礎。無論是漏洞掃描器、SIEM（安全資訊與事件管理系統）、修補程式工具，還是合規框架，全都基於一個假設：當 CVE 出現在 NVD 中時，NIST 的分析師會立即補充嚴重性評分、產品版本對應資訊以及背景元資料，使原始的 CVE 編號真正發揮實用價值。
2026年4月15日，這項假設正式不再成立。
NIST 宣布，NVD 將轉向基於風險的資料增強模式。 大多數新進入資料庫的 CVE 將不再預設獲得 NIST 提供的 CVSS 分數、CPE 產品對應關係，以及獨立分析。對於那些依賴 NVD 增強資料來運作漏洞處理流程的組織而言，這將造成一個真實且日益嚴重的覆蓋範圍問題。對於將該資料嵌入其工具中的安全產品開發人員和供應商來說，這更引發了一個尖銳的問題：現在您的資料饋送究竟在告訴您什麼？
NVD 已無法及時跟上通報的漏洞數量
根據美國國家標準與技術研究院（NIST）的公告，2020 年至 2025 年間，CVE 漏洞通報數量增長了 263%，而 2026 年第一季的通報數量，已較去年同期高出近三分之一。
美國國家標準與技術研究院（NIST）在 2025 年擴充了近 42,000 項 CVE 資料，較以往任何一年都增加了 45%。然而，這項生產力的提升仍不足以跟上日益增加的提交量，因此建立了正式的分流系統。
自 2026 年 4 月 15 日起，NIST 將僅針對出現在 CISA 的 KVE（已知遭利用漏洞）目錄中、聯邦政府使用的軟體，或根據第 14028 號行政命令被指定為關鍵的軟體所涉及的漏洞進行資料豐富化處理。其餘所有漏洞將列於 NVD 中，但不會包含 NIST 添加的豐富化資料，且不會立即進行處理。
因此，近 30 萬筆於 2026 年 3 月 1 日前發布但尚未處理的 CVE，已全數移至「未排程」類別。
今後，對於不符合 NIST 優先級標準的 CVE，其嚴重性評分將取自 CVE 編號機構（通常為受影響軟體的供應商）自行通報的數值，而非來自 NIST 的獨立分析。此外，當 CVE 編號機構已提供嚴重性評分時，NIST 亦將不再重新計算該評分。
每款主要的漏洞掃描工具、每條 SIEM 關聯規則、每項第三方風險評分，以及從 PCI DSS 到 FedRAMP 的每項法規遵循框架，皆仰賴 NVD 資料增強管道。
隨著此次更新，該流程現已正式收緊，導致某些潛在危險的 CVE 未能被歸類為此類，或未能及時發現。
還有一個值得理解的加速因素，那就是「威脅分析深度」的降低，正與「人工智慧輔助的威脅偵測」的快速普及形成相互作用。
先進的人工智慧模型與編碼工具，正大幅降低識別應用程式中可被利用的弱點及複雜攻擊路徑的門檻，進而導致 CVE 披露數量激增。2026 年 2 月，事件應變與安全團隊論壇（FIRST）預測，2026 年將有創紀錄的 50,000 項新增 CVE 被通報。目前的資料豐富化基礎設施尚無法在維持原有品質水準的前提下，處理如此龐大的數量。
為何僅基於 NVD 開發的產品會出現問題
一份 原始的 CVE 記錄通常包含 ID、描述及參考資料。驅動 自動化漏洞管理的元數據，歷來 皆來自 NVD 的分析師。這些資料包含經獨立驗證的 CVSS 嚴重性 評分、CPE 產品對應關係，以及 CWE 弱點分類。
但 正是「增強」讓 CVE 具備可操作性。若缺乏這項功能， 依賴它的作業流程將會以可預見的方式退化。
基於 CVSS 的優先級排序效果減弱
當掃描器或修補工具預期會收到 NVD 提供的嚴重性評分，卻未找到相關資訊時，該漏洞可能會被標示為「嚴重性未知」、超出服務水準協議 (SLA) 驅動的修補政策範圍，或被降為次要優先級。
美國國家標準與技術研究院（NIST）於 2026 年 4 月發布的更新確認：
- 不符合新優先級標準的 CVE 不會自動獲得獨立評分
- 當某個 CNA 已提供 CVSS 分數時，NIST 將不再自行生成分數（即使該 CNA 即是受影響軟體的供應商）
CPE 映射不完善或缺失會導致 CVE 偵測效果不佳
NVD 的官方文件將產品識別描述為資料豐富化的核心環節，因為它能讓使用者透過程式化方式檢查已知漏洞是否影響其環境中的產品。
如果 CPE 對應關係缺失、不完整或延遲，那些主要依賴 CPE 比對的工具可能會無法顯示比對結果，或延遲顯示比對結果。
安全產品供應商是受影響最深的群體之一，因為他們的產品通常仰賴 CPE 比對與 CVE 資料強化。修補程式管理、端點防護、網路存取控制及資產管理工具，皆需倚賴精準的漏洞情報，才能判定哪些系統受到影響、問題的嚴重程度，以及應採取何種後續行動。
對於正在開發新安全產品的團隊而言，若僅以 NVD 作為起點，等於是在一個可能已存在關鍵缺口的基礎上進行開發：零日漏洞的涵蓋範圍有限、針對日益增加的 CVE 資料缺乏豐富化處理，且更新週期可能難以跟上 AI 技術在漏洞發現與利用方面的發展速度。
對於已具備修補或修復能力的團隊而言，風險雖有所不同，但同樣重要。修復引擎的效能取決於其接收到的漏洞情報品質。若該情報不完整、延遲，或過度依賴源自 NVD 的增強資訊，下游工作流程可能會遺漏受影響的產品、降低未知嚴重性漏洞的優先級，或未能在風險暴露加劇前採取行動。
如果這些產品繼承了 NVD 的缺陷，那麼這些缺陷可能會傳遞給每一位下游客戶。
這正是 OESIS 框架漏洞評估所旨在解決的缺口：協助資安產品團隊強化漏洞情報，而不僅僅依賴 NVD 的資料擴充。
OPSWAT 對此OPSWAT 何種不同的做法
OPSWAT 特別為需要將可靠且可操作的漏洞資料嵌入其工具中的資安產品開發人員OPSWAT OESIS Framework 漏洞評估模組。
以「空隙」為設計核心
該模組整合了多個來源，而非僅依賴單一來源。
它利用各種商業與開源漏洞資料來源，確保能及時、準確地涵蓋數百家供應商及應用程式。
OESIS 漏洞目錄目前涵蓋超過 65,000 個獨特的 CVE 編號及 150,000 多個漏洞實例，且會持續更新——每天更新數次——而非等待 NVD 的處理週期。
一種超越 CVSS 的專有嚴重性評分系統，能提供更豐富的背景資訊。
OPSWAT漏洞資料包含「OPSWAT 」，這是一項專有評分機制，其評分標準超越了 CVSS 基礎模型，融入了更多指標，包括 CVE 的普及度、遭入侵風險以及 CVE 的生命週期。
在 CVSS 分數中由 CNA 自行申報的比例日益增加的環境下，這層獨立的分析機制有助於安全產品為使用者提供更具說服力的優先級評估依據。
OESIS 漏洞情報支援兩種整合路徑，且無需複雜的導入流程：
- 目錄資料饋送：在伺服器端將 OESIS 漏洞資料與您的現有軟體清單進行比對——無需端點代理程式。具備軟體清單功能的現有產品可利用 OESIS 資料，在受管資產中偵測漏洞。
- Endpoint （Software 套件）： 將 OESIS 框架直接嵌入您的產品中，以實現即時、在裝置上的vulnerability detection。非常適合在端點上運行的安全產品
內部漏洞研究
OPSWAT 內部威脅研究團隊「Unit 515」持續針對關鍵基礎設施與企業軟體進行 進攻性安全研究、對抗性模擬、進階測試及負責任 披露。該團隊已 發現並通報超過 50 項零日漏洞，其中包括 廣泛部署軟體中的重大發現，例如 Delta PLC 等 ICS/OT 平台 以及原生 AI 平台。
對 資安產品開發者而言，其最終效果是：即使 NVD 的資料豐富化範圍有所縮減，他們的工具仍能維持 更廣泛的漏洞覆蓋率——且無需 讓客戶接受可視性降低或採取手動解決方案。
偵測 + 修復：完整循環
偵測功能用於識別存在漏洞的項目，修補功能則用於解決這些問題。兩者結合，有助於盡可能地封堵風險環節。OESIS 漏洞評估負責執行偵測與優先級排序。若團隊希望在單一框架下同時具備這兩項功能，可選用OESISPatch Management：
- 偵測： 存在漏洞的應用程式、版本匹配、OPSWAT ，以及標記為 KEV 的項目
- 優先順序設定： OPSWAT 能根據實際的攻擊跡象，協助釐清應優先處理的項目
- 解決方案： 您的現有管道可處理 OESIS 輸出——或者 OESISPatch Management 修補、強制版本或封鎖存取
- 驗證： OESIS 會重新掃描後綴，以協助確認端點是否已清除，然後才恢復存取權限
僅進行偵測而不採取修復措施，僅是一份報告；若能結合偵測與修復，則代表風險已獲解決。OESIS 致力於為您的產品提供這兩項功能，協助您更快地完成偵測與修復的閉環流程，從而更有效地應對以 AI 速度出現的威脅。
AI-Speed 漏洞需要 AI-Speed 偵測
資安產品絕不能將漏洞情報視為一種更新緩慢的後端依賴項。隨著 CVE 數量不斷增加，且資料豐富度的品質日益不穩定，產品團隊需要一種方法，讓偵測、優先級排序及修復的工作流程能與實際的風險暴露狀況保持同步。
這正是 OESIS Framework 漏洞評估的用武之地。它為產品開發者提供了一種實用的方法，讓他們無需從頭重建端點或修復架構，即可強化漏洞覆蓋範圍。對於正在推出新產品的團隊而言，它能協助更早建立可信的覆蓋範圍；對於正在改進現有產品的團隊而言，它則提供了一種更順暢的方式，用以比較覆蓋範圍、驗證改進成效，並決定更深入的整合應如何實現。
