Dependabot 預設冷卻期：依賴更新慢三天為何更安全

來源: https://github.blog/security/supply-chain-security/the-case-for-a-cooldown-why-dependabot-now-waits-before-issuing-version-updates/

GitHub 調整 Dependabot 版本更新 pull request 的預設節奏：一般版本更新會先等待三天冷卻期，然後才建立 PR。這反映軟體供應鏈安全的現實變化。維護者、研究人員和下游團隊需要時間發現惡意版本、錯誤發布或相容性問題，避免新套件在大量程式庫中被自動擴散。

重點：稍慢的自動化也能更安全

對 BTTC 讀者來說，這也是選擇開發者工具的重要訊號。自動化不應只追求最快，還應提供安全預設、政策開關和人工審查路徑。瀏覽 BTTC 軟體目錄 或 BTTC 部落格 時，也能用同樣標準評估 CI、程式碼審查、套件掃描和生產力工具。

這個預設值為何此刻重要

冷卻期不是忽略更新，而是把一般版本升級與緊急安全修復分開。三天窗口能讓社群檢查套件內容，讓掃描器發現異常，讓維護者發布修正版，也讓團隊在收到 PR 時擁有更多上下文。如果所有依賴一發布就進入佇列，審查者容易疲勞，自動合併也會變危險。

三天緩衝真正帶來什麼

現代應用程式依賴龐大的開源套件圖譜。專案可能包含直接依賴、傳遞依賴、建置外掛、測試框架和發布工具。近年出現的惡意套件、被盜維護者帳戶、意外破壞性更新和 registry 污染都說明，速度本身不是安全策略。GitHub 公告把常見經驗變成預設防護。

團隊該如何調整依賴政策

冷卻期在上游發布與下游採用之間建立緩衝。早期使用者的問題報告、維護者補丁、registry 移除和安全公告，都可能在這段時間出現。但它不能取代漏洞管理，關鍵 CVE 仍需要快速通道、負責人和緊急部署。

挑選工具時該注意哪些控制

團隊應把依賴更新分成通道：關鍵安全修復走快速通道，一般 patch 和 minor 使用冷卻期，major 升級需要遷移計畫和相容性檢查。正式環境依賴至少需要 CI 通過和人工審查；建置、認證、加密和部署相關套件應要求更高核准。

本週可以執行的檢查

評估依賴管理、CI、程式碼審查或發布自動化工具時，不要只聽「更快」。應檢查是否支援冷卻期、分組規則、嚴重性路由、稽核記錄、忽略規則到期和公告連結。好工具應提供清楚預設值和可控例外，而不是把風險藏在便利性背後。

常見問題

本週可以檢查依賴機器人涵蓋哪些生態、檢查頻率、是否區分安全更新和一般更新，以及誰負責審查佇列。若使用自動合併，只讓它處理低風險套件並確保測試與回復可靠。也要檢查事故預案：如何暫停機器人、固定版本、回滾套件、清理快取和撤銷 token。

結論

Dependabot 冷卻期會讓專案更不安全嗎？

不一定。它放慢一般版本更新，但緊急安全修復仍可走快速通道。

依賴機器人適合自動合併嗎？

低風險更新在測試充分且可回復時可以自動合併；高影響依賴應人工審查。

最佳冷卻期是多久？

三天是實用預設值，但應依套件重要性、發布頻率、測試覆蓋和風險承受能力調整。

額外實施建議

如果團隊已使用 Dependabot 或類似機器人，可以先在一個儲存庫試行冷卻期，並記錄 PR 數量、失敗率、回滾次數和審查時間。安全團隊也應把關鍵套件清單寫入文件，例如認證、加密、部署、建置和遙測相關依賴。如此一來，自動化工具不只減少重複工作，也能讓審查者把注意力放在真正高風險的變更上。

指標與治理

團隊還應把冷卻期和安全指標結合起來，例如平均更新時間、關鍵漏洞修復時間、自動合併比例、失敗建置數量和回滾次數。只有記錄這些指標，才能判斷策略是否真的降低風險，而不是只是讓佇列變慢。