安全團隊對其環境的能見度前所未有，但確認他們修補的措施是否能持續奏效的能力卻前所未有地糟糕。
Mandiant 的 M-Trends 2026 報告估計，平均被利用時間為負七天。Verizon 的 2025 DBIR 報告指出，邊緣設備漏洞的中位修復時間為 32 天。這些數字可以理解地推動了業界採取明確的回應：更好地優先排序，更快地修補。這個建議是必要的。但它並不完整。因為仍然沒有得到足夠關注的問題是：當你確實修補了，你怎麼知道它奏效了？
圍繞 AI 影響的討論集中在速度上：漏洞利用開發變得更便宜、更快，並且越來越不依賴頂尖的人類技能。
對於修復而言，這改變了風險。許多修補措施被標記為「已修復」，但實際上發生的是一個可能被繞過的供應商修補程式，或是一個依賴攻擊者採取特定行為的權宜之計。過去這些都是足夠安全的賭注。但現在不再是了。問題不再是修復的速度。問題在於你的修復是否真正消除了暴露，還是僅僅將工單移至「完成」。
並非所有暴露都可以修補。例如，一個薄弱的防火牆規則會讓門戶敞開。人們發現策略規則被重寫並據報已應用。但真的是這樣嗎？當應用修補程式時，你會得到確認。當設定了權限，或配置了 EDR 策略或 SIEM 設定時，需要進行測試來驗證它是否生效。
即使是經過驗證的高訊號發現，識別和修復之間的延遲主要是組織性的。你發現了風險。但你並不負責修復。負責修復的團隊有不同的時間表和不同的優先級。發現的風險沒有被整合為工程團隊可以執行的動作，因此訊號再次丟失。
在雲端原生和混合環境中，所有權變得更加模糊：漏洞可能存在於應用程式層、基礎設施層，或第三方依賴項中。一旦它落到某個地方，修復就會通過該團隊已經使用的任何流程進行，IT 和 DevOps 的變更窗口，以及工程團隊的衝刺承諾。安全發現最終會與已經在排程上的任何事情競爭，而且它們通常會輸。AI 加速的攻擊者不會等待下一個變更窗口或下一個衝刺。
營運上的阻力有實際的解決方案。整合相關的發現，以便幾個追溯到同一錯誤配置的負載平衡器的已驗證問題，變成一個由單一負責人處理的工單。自動化路由、分配、SLA 執行和升級路徑。將工作流程從試算表和 Slack 訊息中移出。
但吞吐量和速度告訴你系統移動的速度有多快，而不是它是否在工作。你可以將一個整合的工單在幾分鐘內路由給一個已確認的負責人，執行 SLA，按時升級，然後仍然關閉一個沒有消除暴露的工單。也許權宜之計在配置變更後將無法維持，修補程式只應用於四個受影響系統中的三個，或者修補程式雖然成功應用，但周圍的錯誤配置仍然存在。
工單上寫著「已解決」。但攻擊路徑仍然敞開。當 AI 可以像 Mythos 所展示的那樣自主地推導和重新推導利用鏈時，虛假的信心是你安全計畫中最昂貴的東西。
重新驗證應該意味著風險不再存在。重新測試僅驗證原始攻擊不存在。你應該驗證風險本身不存在。
當每一個修補都經過重新測試，並且結果對安全和工程領導層都可見時，部分修補和權宜之計會立即被標記出來，而不是在儀表板中潛伏。它創造了一個反饋循環，使整個系統能夠自我糾正。
在當前條件下能夠維持的修復工作流程：經過驗證的發現被整合為修復動作，路由給已確認的負責人，追蹤直到關閉，然後重新驗證以確認底層風險已消失，而不僅僅是原始攻擊路徑。Pentera 的平台專為該操作模型設計，將修復工作流程與修補後驗證相連接，以便團隊能夠衡量風險是否真正被消除。
那些能夠正確處理這些組織的，將是那些不再將修復視為安全工作完成後的事情，而是將其視為衡量安全工作真正成效的地方。