在現代軟體開發中，我們高度依賴開源套件來加速開發，但這也帶來了供應鏈攻擊（Supply Chain Attack）的風險。所謂供應鏈攻擊，是指攻擊者不直接攻擊你的程式碼，而是將惡意程式碼植入你所使用的第三方套件中。一旦你更新套件，惡意程式碼就會在你的開發環境或生產環境中執行。
為了降低這種風險，GitHub 最近為其自動化依賴更新工具 Dependabot 引入了冷卻期（Cooldown）機制。
為什麼需要冷卻期
在典型的供應鏈攻擊場景中，攻擊者可能會上傳一個含有後門或惡意腳本的「中毒套件」到公開的套件倉庫（如 npm 或 PyPI）。這些中毒版本通常生命週期很短，因為一旦被社群發現，管理員會迅速將其撤回（Yank）或刪除。
然而，對於許多開發者來說，Dependabot 的自動化更新速度太快了。如果 Dependabot 在中毒套件發佈後的幾分鐘內就自動開了一個 Pull Request (PR) 且開發者直接合併，那麼惡意程式碼就會在套件被刪除前成功入侵系統。這就是所謂的爆發半徑（Blast Radius）擴大。
冷卻期的運作邏輯
GitHub 現在將 Dependabot 的預設冷卻期設定為三日。這意味著當一個新版本的套件發佈後，Dependabot 會等待三天，確認該版本沒有被舉報為惡意版本後，才會開 PR 建議你更新。
這裡有兩個重要的技術細節需要注意：
第一，冷卻期僅適用於一般版本更新（Version Updates）。這類更新旨在保持套件最新，但風險較高。
第二，安全性更新（Security Updates）不受冷卻期限制。如果該更新是為了修復已知的漏洞（CVE），Dependabot 會立即發出警報並開啟 PR，因為此時修復漏洞的急迫性高於擔心中毒的風險。
三日這個數字的考量
GitHub 認為三天是一個平衡點。大多數的快閃式中毒套件會在三天內被發現並移除，因此這個時間窗能避開大部分的自動化攻擊。同時，三天的延遲對於一般功能的更新來說，並不會對開發進度造成顯著影響。
開發者的實務建議
雖然冷卻期提供了一層緩衝，但它並非萬能藥。對於那些潛伏期較長、由內部維護者背叛或建構系統被劫持的深度攻擊，冷卻期完全沒有作用。因此，工程師在實務上應採取多層防禦（Defense in Depth）：
首先，必須使用 Lockfiles（如 package-lock.json 或 poetry.lock）來鎖定依賴版本的雜湊值，確保環境的一致性。
其次，在 CI/CD 流水線中，應儘量禁用套件安裝時的安裝腳本（Install Scripts），因為許多惡意程式碼正是透過這些腳本在安裝階段執行。
最後，不要盲目信任自動化 PR。即便經過冷卻期，在合併更新前仍應檢查變更日誌（Changelog）或對關鍵套件進行簡單的審查。
產業趨勢
這種「延遲信任」的趨勢已在多個生態系中出現。例如 VS Code、npm、Yarn 以及 Ruby 等工具都推出了類似的控制機制。此外，Python 的 PyPI 也在規劃防止維護者在發佈 14 天後修改舊版本文件的措施，以防止攻擊者劫持 Token 後對舊版信任套件下毒。
來源：thehackernews.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。