Dependabotは、packageの新versionがregistryで公開されてから少なくとも3日経つまでversion update pull requestを作らない既定動作へ変わった。新version直後の侵害や破損がコミュニティで発見される時間を確保する供給網対策である。security updateは遅延しないため、通常更新と脆弱性対応を分けて運用する必要がある。
何が変わったか
github.comの全対応ecosystemで、Dependabot version updatesへ3日間のdefault package cooldownが自動適用される。.github/dependabot.ymlに設定がなくても有効になる。GHESでは3.23から反映される。cooldown optionで期間変更またはopt-outが可能である。
変更前後の差
従来はscheduleに到達すると、registry上の新versionを直ちにPR候補にできた。変更後はscheduleがdailyでも、公開後3日未満のversionは通常のversion update PRにならない。security updateは引き続き即時であり、脆弱性修正を3日待つ仕様ではない。
誰に影響するか
頻繁にdependencyを更新するapplication、container、GitHub Actions、Terraform module、language packageを管理するteamが対象である。release直後の機能を即採用する製品、internal packageで公開直後の同期が必要なmonorepo、更新遅延をSLAに含めるplatform teamは設定見直しが必要になる。
期限
設定変更の期限はない。既定値は自動適用されるため、従来どおり即時PRが来る前提のautomationがある場合は早めに確認する。
必要な対応
Dependabot PR作成時刻を監視しているdashboardやSLAを3日分調整する。即時性が必要なpackageだけ例外化し、全体opt-outは避ける。security updateとversion updateを同じqueueやmetricで集計している場合は分離する。
実装・移行手順
- 全repositoryの
dependabot.ymlとupdate scheduleを収集する - release直後の採用が必要なdependencyを特定する
- default 3日を維持するrepositoryを明示する
- 例外が必要な場合だけ
cooldownを設定する - test packageで公開日時とPR作成日時を記録する
- security advisoryを使いsecurity updateが遅延しないことを確認する
- PR backlog、merge時間、rollback率を比較する
失敗しやすい点
security updateまで遅れると誤解する、daily scheduleなら毎日必ず新version PRが出ると思う、internal registryのrelease pipelineと同期できなくなる、全dependencyを一律opt-outする、といった問題が起きやすい。cooldownは品質保証ではなく観測時間を増やすだけである。
リスク
3日間に必要なbug fixや互換対応が遅れる、逆に例外を増やしすぎて供給網リスク低減効果を失う、PR数の減少を更新停止と誤認するリスクがある。release ageだけでは署名、provenance、maintainer変更、malware判定を保証できない。
評価方法
- package公開からPR作成までの時間
- release直後に撤回・yankされたversionの回避件数
- version update PR backlog
- security updateの作成時間
- cooldown例外package数
- merge後rollback率
- dependency freshnessの中央値
ロールバック
即時更新へ戻す必要がある場合は、対象update blockへcooldown設定を追加して期間を短縮または無効化する。変更は小数repositoryから適用し、PR急増を確認してから広げる。問題があれば設定commitをrevertし、既定3日へ戻す。
編集部分析
default cooldownは「最新を最速で取り込む」ことを安全性の指標としない変更である。重要なのは待機日数そのものではなく、待機中に何を観測するかだ。release撤回、malware alert、maintainer声明、CI failureを自動収集できなければ、3日後に無条件mergeするだけになる。
実務チェックリスト
- [ ] version updateとsecurity updateを区別した
- [ ] 3日待機をSLAへ反映した
- [ ] 即時採用が必要なpackageを限定した
- [ ] 全体opt-outを避けた
- [ ] PR作成日時を監視する
- [ ] rollback率とrelease撤回を評価する
- [ ] 設定revert手順を確認した