隨著人工智慧加快漏洞的發現與利用速度，軟體業者面對新漏洞時的反應時間進一步被壓縮。Google的安全研究團隊Project Zero近日指出，當高風險漏洞已經遭到積極利用，對軟體業者而言，如何在最短時間內降低使用者的曝險程度更顯重要。因此，Project Zero呼籲軟體業者不能只仰賴加快修補程式的開發，還應該事先建立緊急應變機制，以便在正式修補完成之前先降低風險，提高零時差漏洞的利用難度。
Project Zero指出，緊急修補的難點在於，廠商既要盡快降低漏洞遭到利用的風險，又必須完成必要的測試與部署程序。完整的軟體更新仍需要經過測試與派送，部分更新還需要重新啟動才能生效，其中測試與更新部署更是難以大幅壓縮的環節。為此，團隊整理出四類可以在正式修補完成前採取的應變方式，包括功能開關、輸入過濾、替代更新管道，以及熱修補。
第一種作法是功能開關，可以透過遠端設定切換或暫時停用特定功能。例如蘋果公司曾在群組視訊通話功能爆發重大漏洞時暫停相關功能；最近也有社群媒體業者公開新採用的通訊協定設計，將新舊兩個版本同時保留，若新版出現問題，就能快速切回舊版。Project Zero指出，這類作法的優勢在於，業者可以事先測試不同設定狀態下的表現，因此發生緊急狀況時，不必為了快速應變而派送未經測試的新程式碼。
第二種作法是輸入過濾，可以透過動態更新規則，阻擋觸發特定漏洞所需的輸入。例如安卓系統的意圖防火牆，可以依據規則限制特定意圖的使用方式，在正式修補推出前先阻擋部分攻擊路徑。相較於功能開關必須事先規畫哪些功能可以被切換，輸入過濾更具彈性，可以在漏洞出現之後，再針對特定輸入建立規則。
第三種作法是替代更新管道，可以讓特定元件不必等待完整的系統更新，就能透過較快的管道個別更新。這部分以安卓系統的模組化更新機制為例，可以更快速地更新部分高風險系統元件，而且設備製造商不必再將元件更新整合至完整的系統更新，因此可以縮短修補開發時間。但要注意的是，若透過網路另外下載元件，仍必須嚴格驗證來源，以免快速更新機制本身成為新的攻擊面。
第四種作法是熱修補，可以將較小單位的二進位程式碼直接套用到執行中的程序。例如Linux的即時修補機制可以替換執行中的核心函式，不必重新啟動；Windows的熱修補也能只派送更新過的函式，並在程序執行期間直接套用。不過要留意的是，熱修補能修補的類型有限，而且主要解決的是更新派送速度，仍然不能省略快速更新所需的測試。
Project Zero強調，快速更新機制不必能夠修補所有漏洞，也不必在任何情況下都完全維持原有的使用體驗，只要能在短期內處理最可能或最嚴重的漏洞，就能在緊急情況下發揮作用。因此，軟體業者應該盤點現有的更新機制，並針對不足之處增添快速修補能力，以因應大規模漏洞遭到積極利用的最壞情況。
這項呼籲背後反映的是資安攻防節奏的改變。當AI工具讓攻擊者可以更快找到漏洞、更快發展出利用方式，傳統「等正式修補發布再派送」的流程就顯得太慢。中間的空窗期越長，使用者暴露在風險中的時間就越久。事先準備好的緊急應變機制，等於是為軟體業者爭取緩衝時間，讓防守方在正式修補完成之前，先把最危險的攻擊路徑堵住。
對於一般使用者來說，這類機制其實並不陌生。許多人曾經遇過某些應用程式功能突然被暫時關閉，或是系統在背景悄悄更新了某個元件而不需要重新開機，這些都可能是業者啟動緊急應變的痕跡。重點不在於每次都做到完美，而是在漏洞遭到大規模利用的最壞情況下，手上有可以立刻出手的工具。
值得注意的是，這四種作法並非互相排斥，業者可以依照產品架構組合使用。例如先用功能開關停用有問題的功能爭取時間，同時透過替代更新管道派送關鍵元件的修正，最後再以完整的系統更新收尾。Project Zero的整理，等於是為軟體業者提供一份應變工具箱的清單，提醒業界在AI加速攻擊的時代，把「修補前的應變」列入標準流程。
