Dependabot 預設延遲三天更新
GitHub 替 Dependabot 的一般版本更新加上預設三天「冷卻期」：套件發布新版後，不會立刻送出更新 Pull Request，而是先讓維護者、安全研究員與自動掃描工具有時間檢查。這主要防範供應鏈攻擊利用自動更新的速度，把剛上架的惡意版本送進 CI/CD；已公開漏洞所觸發的安全更新則不受影響，仍會立即處理。
現實應用
只要專案透過 Dependabot 管理 npm、pip、Maven、Docker、GitHub Actions 等相依項目，都能直接受益，尤其是更新頻繁、依賴大量開源套件的 SaaS 團隊與平台工程部門。過去熱門套件遭入侵後，即使兩小時內下架，也足夠自動工具建立 PR；三天等待期可避開這種短命但擴散很快的惡意版本。
期望評估
我認為低標效果，是減少團隊在第一時間碰到明顯有問題的新版，也降低 CI 無謂執行與工程師審查 PR 的成本。高標來看，我猜它能讓「搶快升版」不再是預設行為，逐步改變整個開源生態的更新節奏。
但冷卻期不是萬靈丹。潛伏較久的後門、維護者蓄意破壞或建置系統遭入侵，都可能躲過三天觀察；lockfile、限制 CI token 權限、停用不必要的 install script，以及人工審查仍然要做。
商業策略分析
GitHub 把安全預設值往前推，受影響最大的是其他依賴更新服務與企業內部自動化工具：若仍主打「新版一出就升」，反而得解釋風險。我認為這是低成本、高覆蓋率的產品調整，也讓 GitHub Advanced Security 的供應鏈安全敘事更完整。企業值得跟進，但應依套件來源分級；可信任的內部套件可以縮短等待，公開 registry 或高風險依賴則可拉長。
實作細節
新預設已自動啟用，不必修改設定。需要調整時，可在預設分支的 .github/dependabot.yml，於對應 updates 項目加入 cooldown。可設定 default-days，也能分別指定 major、minor、patch 的等待天數，並用 include、exclude 篩選套件。已知限制是 cooldown 僅套用一般版本更新，不會延遲安全更新。