您的應用程式可能早已失去安全性，只是您還尚未察覺。

長久以來，資安領域普遍存在一項看似合理的假設：只要在 CVE 漏洞資訊公開後的 30 天內完成修補，便足以有效降低遭受攻擊的風險。然而這項假設如今已不再成立。在 AI 技術加持下，資安工具已能更快速地識別漏洞，並將其轉化為可被利用的攻擊手法，其速度往往超越多數組織的防禦與修補能力。2019 年時，企業在漏洞揭露後通常還擁有約 22 天的時間進行風險評估與修補；然而，隨著攻擊自動化與 AI 技術的發展，這段時間如今已急遽壓縮至以分鐘計算。

甚至出現一些漏洞的平均利用時間（MTTE）已提前至漏洞公開之前，意味著當漏洞資訊正式揭露時，攻擊者早已開始發動攻擊。

新的攻擊時間軸究竟是什麼樣子？

要理解現代威脅態勢，就必須重新思考「及時修補（timely patching）」的真正意義。過去的模型建立在一個可預期的流程之上：漏洞被發現、CVE 公開與修補程式同步釋出、修補程式經測試驗證、最後完成部署。每一個環節通常都需要數天甚至數週才能完成。然而，在當前的現實環境中，這樣的模型已經不再適用：

• T0－漏洞已經存在。此時生產環境中已存在系統缺陷，但尚未對外公開揭露。在這個階段，進階的 AI 模型可能已經率先發現該漏洞，使攻擊者得以開始進行大規模探測與嘗試利用。
• T0 + 數小時－Oracle 的季度 CVE 通報一發布，Azul 隨即跟進公開相關資訊。隨著漏洞資訊被揭露，攻擊者的自動化漏洞利用生成流程也同步啟動。當你還在等待 OpenJDK 供應商的修補程式更新套件（PSU，Patch Set Update）釋出時，修補時間其實已經所剩無幾。
• T0 + 24–48 小時－攻擊活動已進入實際利用階段，武器化的攻擊程式碼也開始在各種管道中流通。此時，多數組織仍在等待 OpenJDK 供應商的修補程式更新套件（PSU，Patch Set Update）釋出。
• T0 + 30 天－修補程式部署完成（傳統節奏）。到了這個時間點，採取「盡力而為」式修補策略的組織，其實早已在數週前就暴露於風險之中。

漏洞利用（vulnerability exploitation）如今已超越電子郵件釣魚與憑證竊取，成為攻擊者最主要的入侵入口。

過去那種「有空再修補」的資安態度，現在已不再只是策略選擇，而是會直接轉化為風險負債與潛在責任。

無支援的 Java 是否正在加劇你的修補困境？

如果你的組織仍在使用無支援的 Java(例如免費但無保固的Java)，修補挑戰往往會以不易察覺的方式被進一步放大。在這種情況下，通常只能取得季度性的修補程式更新套件（PSU）。而這些更新通常會比 Oracle 的 Critical Patch Updates（CPU）版本延遲數天至數週，其他 OpenJDK 供應商才釋出 PSU 版本。

這樣的延遲，將原本有限的修補時間窗口轉變為長期暴露的風險缺口。即便組織具備快速修補的意圖，實務上仍常受限於架構與流程，難以即時完成部署。結果便是修補意圖與執行之間產生落差，而攻擊者正持續利用這一斷層。

如何才能讓 Java 修補速度足以超前 AI？

Azul 透過提供以資安為優先設計的 Critical Patch Updates（CPU），來填補這一落差，並作為修補程式更新套件（PSU）之外的另一種明確替代方案：

• CPU（Critical Patch Updates）僅包含關鍵的資安修補，並建立在先前已穩定、經社群驗證的修補版本之上。Azul 以分鐘為單位完全跟上Oracle 釋出速度，並讓 CPU 以可程式化方式提供，使其能在發布後即時整合進 CI/CD 流程，讓修補程式可以在第一時間自動化部署，縮短修補落差。

•  

  補程式更新套件（PSU）通常包含數百項錯誤修正、功能改善、安全性更新等內容。因此，在實際部署前需要進行大量測試，進一步拉長整體修補週期。此外，根據統計，約有四分之一的 PSU 會引發回歸問題（regression issue），釋出的版本其實是有問題而無法應用的，導致企業必須等待「修補的修補」，進而造成額外數天至數週的延遲。

   

除了 CPU 之外，Azul 也針對零時差漏洞（zero-day vulnerabilities）與關鍵功能回歸問題（critical functional regressions）提供非週期性的緊急更新，確保最緊急的安全與穩定性問題，不必等到下一個季度版本才得以修復。這種做法的主要優勢包括：

• 最小化影響範圍（Minimal footprint）CPU 僅包含關鍵修補與資安更新，大幅降低部署前所需的測試成本與時間。
• 嚴格 SLA 交付（Strict SLA delivery）CPU 依照可預期的固定排程交付，使資安團隊能夠更有效規劃修補作業並快速執行。
• 零時差漏洞覆蓋（Zero-day coverage）透過非週期性緊急更新機制，針對最嚴重的零時差漏洞提供即時修補，不需等待季度性發布週期。

安全的底線：Java 的安全性，取決於修補速度

資安修補的節奏，必須跟上 AI 驅動威脅持續演進的速度，而不是被測試流程所限制。能在快速取得更新但無法快速部署的修補程式，其實與沒有修補差距相去不遠。

隨著 AI 不斷壓縮漏洞利用的時間窗口，真正能維持防護能力的組織，將是那些已重新設計 Java 修補策略、並將「速度」視為核心能力，而不只是「有打算修補」的企業。

若對 Azul 有興趣歡迎留下資訊，將會有專人與您聯繫 ➤ https://www.gss.com.tw/product-services-nav/info-security/azul