安全團隊從未像現在這樣對自己的環境有如此清晰的了解，也從未像現在這樣難以確認他們所修復的問題是否真的得到了解決。Mandiant 的《2026 年 M-Trends 報告》預測，漏洞利用的平均時間為負七天。Verizon 的《2025 年資料探勘與調查報告》(DBIR) 則指出，修復邊緣設備漏洞的中位數時間為 32 天。這些數據促使業界做出了明確的回應：提高優先級，加快補丁修復速度。這些建議固然必要，但並不全面。因為還有一個問題尚未得到足夠的重視：當你打完補丁後，如何才能確定它真的有效？

Mythos並沒有改變問題本身，它只是改變了漏洞被利用的速度和難易度。

關於人工智慧影響的討論主要集中在速度：漏洞利用開發變得越來越便宜、越來越快，而且越來越不依賴精英人類的技能。

對於修復而言，情況就不同了。許多修復都被標記為“已修復”，而實際上可能只是廠商發布的補丁，但這些補丁最終被證明是可以繞過的，或者只是依賴攻擊者特定行為的變通方案。過去，這些修復方案還算可靠，但現在卻不再如此。問題不再是修復的速度，而是你的修復是否真正消除了漏洞，還是只是把工單狀態改成了「完成」。

補丁完美，但仍存在漏洞

並非所有安全漏洞都能透過修補解決。例如，一條薄弱的防火牆規則就可能造成安全漏洞。我們發現該策略規則已被重寫，並且據稱已被應用。但事實果真是如此嗎？套用補丁後，系統會發出確認通知。設定權限、配置 EDR 政策或 SIEM 設定後，需要進行測試以驗證是否生效。

組織中的縫隙，幾週時間就此消失

即使發現了經過驗證的高風險訊號，從識別到補救之間的延遲主要也是組織層面的問題。你發現了風險，但你不負責修復。負責修復的團隊各自按照不同的時間表和優先順序運作。這些發現並沒有被整合為工程團隊可以執行的行動方案，因此訊號再次遺失。

在雲端原生和混合環境中，責任歸屬變得更加模糊：漏洞可能存在於應用程式層、基礎架構層，或第三方依賴項。一旦漏洞出現，修復工作就會按照團隊已有的流程進行，IT 和 DevOps 團隊的變更視窗以及工程團隊的迭代計劃都會影響修復進度。安全發現最終會與既定計劃衝突，而且通常會失敗。而人工智慧加速的攻擊者則不會等待下一個變更視窗或下一個迭代計劃。

整合與自動化是必要的，但它們還不夠。

維運瓶頸有切實可行的解決方案，整合相關發現，將多個經驗證的、源自相同配置錯誤的負載平衡器的問題合併為一個工單，並由同一負責人處理。實現路由、分配、SLA 執行和升級路徑的自動化，讓工作流程擺脫電子表格和 Slack 訊息的束縛。

但吞吐量和速度只能告訴你係統運作的速度，並不能說明系統是否正常運作。你可以在幾分鐘內將合併後的工單分配給已確認的負責人，執行服務等級協定 (SLA)，按計畫升級，但最終可能還是會關閉一個並未消除風險的工單。也許臨時解決方案無法在配置變更後生效，修復程式只覆蓋了四個受影響系統中的三個，或者補丁雖然成功應用，但周圍的錯誤配置仍然存在。

工單顯示“已解決”，但攻擊路徑仍然暢通。當人工智慧能夠像 Mythos 一樣自主推導和重新推導攻擊鏈時，虛假的自信才是安全計畫中最昂貴的因素。

重新認證是缺少的一環

重新驗證意味著風險已不復存在，重新測試只能驗證最初的攻擊是否仍然存在，您應該驗證風險本身是否真的不存在。當每個修復方案都經過重新測試，並且安全性和工程管理層都能看到測試結果時，不完整的修復和臨時方案就會立即被標記出來，而不是停留在控制面板中。這形成了一個回饋循環，使整個系統能夠自我修正。

在當前情況下，有效的修復工作流程是：將已驗證的調查結果整合為修復措施，分配給已確認的負責人，追蹤直至問題解決，然後再次驗證以確認根本風險已消除，而不僅僅是原始攻擊路徑。 Pentera平台正是為這種營運模式而設計的，它將修復工作流程與修復後驗證相結合，使團隊能夠衡量風險是否真正消除。

三個問題將一個體系與一個希望區分開來

你處理已驗證且可利用的漏洞的平均時間是多少？如果你無法回答這個問題，那麼你衡量的是活動，而不是結果。當修復方案實施後，如何確認其有效？如果答案是“工程師關閉了工單”，那麼請問問自己，這些已修復的問題中有多少能夠經受住重新測試。

您衡量的是已關閉的工單數量還是已消除的風險數量？工單吞吐量只能說明團隊很忙，不能說明風險敞口已經消失。只有將調查結果與根本風險進行整合，並追蹤風險是否真正消除，專案才能改進。

那些能夠正確處理這個問題的組織，將不再把補救措施視為安全工作完成後的事情，而是將其視為衡量安全工作成效的真正標準。

資料來源：https://thehackernews.com/2026/05/most-remediation-programs-never-confirm.html