Dependabot 三天冷卻期怎麼用？別把一般更新與安全修補混在一起

為什麼一般版本更新要等三天#

套件剛發布時，維護者與安全研究者還在觀察是否有撤版、惡意植入或明顯相容性問題。GitHub 說明，新預設只作用於 version updates，讓一般升版先避開這段初始窗口；它不是對套件安全性的保證，也不會取代 lockfile、PR review 或 CI 的權限控管。

這個行為適合用在「自動建立一般升版 PR」的情境。已知 CVE 或 GitHub Advisory 對應的修補，屬於 security update，不能因為一般更新有 cooldown，就預期它也會等三天。

先檢查 repository 是否覆寫預設#

在 repository 根目錄先找 Dependabot 設定檔與目前的更新規則：

1
test -f .github/dependabot.yml && sed -n '1,240p' .github/dependabot.yml
2
rg -n 'cooldown|package-ecosystem|open-pull-requests-limit' .github/dependabot.yml

若設定檔沒有 cooldown，一般版本更新會使用 GitHub 的預設行為。需要不同等待時間時，再在對應的 updates 項目加入 cooldown。GitHub 的設定參考列出 default-days、semver-major-days、semver-minor-days 與 semver-patch-days 等欄位；欄位應放在要控制的生態系規則下，而不是隨意加在檔案最外層。

1
version: 2
2
updates:
3
  - package-ecosystem: npm
4
    directory: /
5
    schedule:
6
      interval: weekly
7
    cooldown:
8
      default-days: 3
9
      semver-major-days: 7
10
      semver-minor-days: 3
11
      semver-patch-days: 1

這不是一組通用建議值。舉例來說，內部私有套件、頻繁釋出的小型服務，或有固定維護窗口的 monorepo，可能需要不同分級；設定前先確認 release 節奏、可接受的落後時間與手動緊急升版流程。

冷卻期不是把安全更新延後的理由#

最容易誤判的是「Dependabot 有等待機制，所以安全 PR 也可以慢慢看」。GitHub 明確區分兩種更新：security update 對應已知漏洞，而 version update 是在沒有已知漏洞時保持相對新版本。前者仍要依風險與可用修補版本處理；後者才是 cooldown 要降低初期供應鏈風險的範圍。

我會把 PR 規則切成兩條：一般版本更新進入既有 review queue；安全更新則另有 triage 時限與測試流程。若 workflow 會在 PR 中安裝依賴或取得部署權限，也應延續 GitHub Actions 的 pull_request_target 安全邊界 的做法，避免高權限 job 執行未審核內容。

調整前後各做一次可驗證的檢查#

1. 確認 .github/dependabot.yml 的每個 updates 區塊是否真的套用到目標資料夾與 package ecosystem。
2. 在 PR 或 Dependabot log 中確認這次是 version update 還是 security update。
3. 對一般更新，記錄發布時間、預期 cooldown 與實際建立 PR 的時間；不要只從「還沒看到 PR」推定故障。
4. 對安全更新，確認 alert、修補版本、lockfile 更新與 CI 結果，而不是等待一般更新的排程。
5. 保留 lockfile、最小化 CI token 與人工 review；cooldown 只處理剛發布、很快被發現有問題的其中一條風險路徑。

把冷卻期視為一般版本升級的緩衝，而不是萬用安全開關，才能同時維持修補速度與供應鏈檢查的節奏。

參考資料：

GitHub Blog：Dependabot 為何預設等待版本更新

GitHub Docs：Dependabot options reference