Dependabot 版本更新引入預設套件冷卻期

GitHub 已為 Dependabot 版本更新引入了預設的套件冷卻期。這項變更確保新版本在各自的註冊表（registries）上至少可用三天的時間，Dependabot 才會開啟版本更新的 pull request，從而降低使用者在供應鏈攻擊期間自動採用受損套件的風險。

即時安全更新與延遲版本更新

Dependabot 會區分安全更新與一般版本更新，以確保關鍵修復不會被延遲。雖然一般版本更新現在面臨三天的等待期，但安全更新仍會立即開啟。此機制旨在防止標準版本發佈中引入的惡意代碼快速傳播，同時確保關鍵漏洞修復能盡快送達。

緩解供應鏈風險

冷卻期作為緩衝，讓社群與自動化掃描器有時間在惡意套件透過自動化 PR 廣泛分發之前，偵測並回報惡意套件。透過放慢採用最新版本的速度，GitHub 目標是減少受損套件發佈的影響範圍。

社群對冷卻期有效性的看法

開發者之間的技術討論提出了關於此冷卻期有效性與時機的幾項疑慮：

• 偵測窗口： 有人認為三天窗口可能不足，甚至可能適得其反。一位使用者指出，惡意行為者可以安排在週二發佈漏洞利用程式，並在週五合併，從而可能在修補能力有限的週末期間觸發負載。
• 偵測回報延遲： 有人擔心廣泛的冷卻期可能會推遲發現感染的時機。如果較少的使用者立即更新，可能會有較少的人關注新代碼，從而可能延遲回報受損情況。
• 版本更迭頻率： 一些開發者對不斷更新的壓力表示沮喪，表示更新過於頻繁可能比維持穩定版本更糟。
• 「3天 0-day」： 這種轉變被戲稱為將「0-day」變成「3-day」，突顯了保持最新與保持安全之間的內在緊張關係。

生態系統影響與替代方案

一些開發者建議，安全責任應該轉移到註冊表本身。建議包括對具有高生態系統影響力的套件（例如：下載量達數百萬次的套件）執行更嚴格的安全要求，以防止漏洞在最初進入註冊表時就發生。

對於那些希望在 Dependabot 之外實施類似冷卻策略的人，社群成員已指出可以使用 npm、pnpm 和 yarn 等套件管理器的配置方法來手動管理更新延遲。