當安全團隊考慮生命週期結束 (EOL) 的開源軟體時，討論通常始於同一件事，也終於同一件事：不再提供修補程式。沒錯，但這只是故事的一半，而且可以說是危險性較小的一半。還有兩個相互交織的問題，大多數球隊都沒有意識到。
- 問題一：CVE生態系統不會調查它不支援的內容
當開源專案中發現漏洞時，維護者會確定受影響的版本，並提交一個包含受影響版本範圍的 CVE 編號。業界所有漏洞掃描器、SBOM 工具和 CVE 資訊來源都會使用這個範圍。如果你的版本不在範圍內，你不會收到任何警報。這並不是因為你的版本安全，而是因為沒有人檢查過。
終止支援版本幾乎預設不屬於這個範圍。原因很簡單：這是規模問題。根據Sonatype 發布的《2026 年軟體供應鏈狀況報告》，短短五年內，全球 CVE 數量翻了一番，而未評分的 CVE 數量則增加了 37 倍。維護人員已經疲於應對他們積極支援的版本，而且隨著 CVE 數量和軟體包發布總數的持續增長，覆蓋舊版本所需的調查能力根本不存在。
維護人員必須對自身版本歷史記錄中能夠合理追溯的距離保持務實態度。Sonatype 的研究明確指出：「安全公告中遺漏的 EOL 版本」是造成安全信心不足的因素，導致僅在 2025 年就發現了 167,286 個漏報（完全未被標記的可利用元件）。
實際應用情況如何？Spring 生態系統最近出現的兩個重大漏洞使這一點變得具體化。CVE-2026-22732 — Spring Security（嚴重，2026 年 3 月，CVSS 9.1），此漏洞會導致某些 servlet 應用程式設定中安全回應標頭（包括Cache-Control、X-Frame-Options、Strict-Transport-Security和Content-Security-Policy）被靜默丟棄。官方公佈的受影響版本範圍涵蓋 Spring Security 5.7.x 至 7.0.x。
Spring Security 6.2.x 未列入清單中。它已於 2025 年 12 月停止維護。 Spring Boot 3.2 隨附 Spring Security 6.2。任何執行 Boot 3.2 且版本號低於清單中範圍的組織都將無法接收掃描訊號。
HeroDevs 已確認 Spring Security 6.2.x 版本受到影響，並已向後移植了針對 NES 用戶的修復程序。但上游 CVE 記錄尚未反映此問題。這種情況發生的頻率如何？以上Spring的例子並非個案。它們反映了HeroDevs在其「永無止境的支持」實踐中持續遇到的模式。
當受支援的軟體包中揭露了新的 CVE 時，HeroDevs 發現大約 80% 的情況下，需要修補的是一個已停止維護的版本，而官方 CVE 記錄中並未將其列為受影響版本，任何給定漏洞的影響範圍都係統性地比記錄中顯示的範圍要大。
簡單來說：在支援版本中揭露的每五個 CVE 中，有四個很有可能你正在運行的 EOL 版本也會受到影響，而世界上沒有任何掃描器會告訴你這一點。
- 問題二：產業統計的生命週期結束軟體數量有誤
上述CVE調查缺口指的是社區已知已停止維護的軟體。但實際上，這只是實際問題的一小部分。引用最多的 EOL 資料來源是endoflife.date，它追蹤大約 350 個正在積極維護的專案；這些主要框架和運行時的維護者已經明確發布了生命週期結束日期。
在這350個專案中，大約有7000個特定軟體包版本被標記為已停止維護（EOL）。這就是大多數掃描器和安全團隊所面臨的工作範圍。在Sonatype 與 HeroDevs 合作發布的《2026 年軟體供應鏈狀況報告》中，數據呈現出不同的景象。 HeroDevs 分析了涵蓋 npm、PyPI、Maven、NuGet、RubyGems、Go、Packagist 和 crates.io 等平台的 1200 萬個軟體包版本的生命週期狀態，發現其中 540 萬個版本已經停止維護。
然而，業界最完整的公共來源（endoflife.date）僅涵蓋了其中約 7,000 個案例。按生態系統劃分的情況令人震驚，大約 25% 的 npm 套件版本已停止維護 (EOL)。 NuGet 約為 18%，Cargo 為 13%，PyPI 為 11%，Maven Central 為 10%。這些版本目前仍活躍在企業 SBOM 中，但尚未獲得 CVE 漏洞調查，也沒有修復方案。Sonatype 的報告發現，企業依賴關係圖中 5% 到 15% 的元件已停止維護（EOL），這意味著即使團隊認為他們只使用了受支援的頂級庫，仍然存在 EOL 風險。傳遞依賴項（即你的軟體包所依賴的軟體包）承擔了大部分這種隱性風險。
大多數組織都嚴重低估了其產品生命週期結束（EOL）的風險敞口，這並非他們的錯。他們的工具從未被設計用於大規模檢測產品棄用情況。HeroDevs 已確認超過 81,000 個 EOL 軟體包版本存在已知的 CVE 且沒有可用的修復途徑，這意味著這些 CVE 是經過積極調查和確認的。
鑑於大約 80% 的受支援版本上的 CVE 也影響到從未被官方調查過的已停止維護版本，實際數字可能遠高於此。 HeroDevs 估計，所有註冊機構的實際數字可能接近40 萬以上。
為什麼情況會越來越糟？
這種動態並非新鮮事，新鮮事在於它加速惡化的速度。開源軟體生態系統的發展速度超過了為其建構的安全基礎設施的建設速度。僅 npm 一項，到 2025 年就記錄了超過 83.8 萬個與 CVSS 9.0+ 嚴重評分相關的版本， PyPI 的下載量較去年同期成長超過 50%。
進入註冊表的每個新軟體包版本都是未來的 EOL 版本，而 EOL 版本的數量不斷增長，但調查能力卻沒有相應增長。然而，更重要的驅動因素可能是人工智慧。
2026 年 4 月，Anthropic 發布了 Project Glasswing 以及 Claude Mythos Preview，記錄了其識別和利用所有主要作業系統和瀏覽器上的零日漏洞的能力——包括數十年來未被發現的漏洞。該計劃明確以防禦為目的，旨在攻擊者利用關鍵漏洞之前發現並修復這些漏洞。對於有積極支持的軟體而言，這無疑是個好消息。在人工智慧規模下發現的漏洞可以迅速轉交給能夠解決這些問題的工程師。
對於生命週期結束（EOL）的軟體，情況則有所不同。能夠發現整個程式碼庫漏洞的人工智慧，會發現那些維護人員根本不會關注的版本中的漏洞。而這些漏洞不會被官方針對受影響的生命週期結束版本範圍進行調查。
它們不會觸發針對生命週期結束使用者的掃描警報。上游補丁也不會解決這些問題。這項功能雖然能加速對支援軟體的防禦，但卻擴大了所有已停止維護軟體的風險敞口。
這種轉變的早期跡像已經顯現，但其全部影響尚未到來。
您的技術棧中有多少已經停止維護？
你不知道。你的掃描器不知道。你的CVE資訊來源也不知道。Sonatype 的資料顯示，典型企業技術堆疊中 5% 到 15% 的元件已停止維護（EOL）。僅 npm 一項，所有軟體包版本中就有 25% 已停止維護。 Spring Boot 3.2 隨附了 Spring Security 6.2，後者自去年 12 月起就已停止維護，但掃描器並未發出警報。隨著人工智慧輔助漏洞研究規模的擴大，未調查的生命週期結束軟體包中未揭露的漏洞數量只會增加。
資料來源：https://www.bleepingcomputer.com/news/security/the-eol-blind-spot-in-your-cve-feed-what-sca-tools-miss/