Dependabotのクールダウン：依存関係更新を3日待つ意味

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

GitHub は Dependabot の version update pull request の標準動作を変えました。通常の更新は PR を開く前に三日待ちます。この短い待機は、悪意ある release、壊れた package、security advisory を、広い codebase へ広がる前に見つける時間を作ります。BTTC 読者は BTTC software directory と BTTC blog でも同じ観点で tool を評価できます。

要点：少し遅い自動化が安全を高める

Cooldown は update を無視する仕組みではありません。緊急 security fix と通常 upgrade を分ける仕組みです。三日あれば community の検証、scanner の警告、maintainer の修正版が出る可能性があります。すべてを即時 PR 化すると reviewer は疲弊し、blind merge が起きやすくなります。

この標準設定が今重要な理由

現代の application は巨大な open source graph に依存します。直接依存、transitive 依存、build plugin、test framework、release tool が重なっています。registry 攻撃、maintainer account 侵害、偶発的な breaking change は、速さだけでは不十分だと示しました。

三日間の待機で得られるもの

待機期間は上流 release と下流採用の間に buffer を作ります。issue、advisory、registry 削除、patch release が見えるまでの時間です。ただし critical CVE には fast lane が必要です。通常更新と既知 risk 削減を同じ速度で扱わないことが重要です。

依存関係ポリシーの見直し方

update を lane に分けます。critical fix は高速、patch と minor は cooldown、major は release note と互換性確認を含む計画にします。CI 通過、人間の review、本番依存の owner 確認を設定し、認証、暗号、build、deploy 関連は追加承認にします。

開発者向けtoolで見るべき点

依存管理、CI、code review tool を選ぶときは cooldown、grouping、severity routing、audit log、allowlist、期限付き ignore rule を確認します。これは他の software 選びにも通じます。良い product は便利さと制御を両立させます。

今週の確認リスト

bot が対象にする ecosystem、実行頻度、review 担当、security update と routine update の分離を確認します。incident playbook も確認します。bot 停止、version pin、rollback、cache purge、token revoke を事前に練習すべきです。

よくある質問

Cooldown は project を危険にしますか？

通常更新は遅くなりますが、緊急 security fix は高速経路で処理できます。

Auto-merge は使うべきですか？

低 risk で test が強く rollback できる場合に限定すべきです。重要依存は人間が review します。

最適な待機期間は何日ですか？

三日は実用的な default ですが、重要度、test、ecosystem の速さで調整します。

まとめ

Dependabot の cooldown は、成熟した automation が単に速いだけでなく risk-aware であるべきだと示しています。

導入時の追加ポイント

すでに Dependabot や同種の bot を使っている team は、まず一つの repository で cooldown を試し、PR 数、失敗率、rollback 回数、review 時間を記録するとよいでしょう。security team は認証、暗号、deploy、build、telemetry に関わる重要 package の list も文書化すべきです。そうすれば automation は単なる作業削減ではなく、reviewer が本当に危険な変更へ集中するための仕組みになります。

運用で見落としやすい点

Cooldown を入れても、owner が不明な PR は滞留します。package ごとに担当者を決め、release note を読む基準、test が落ちたときの扱い、例外的に早く merge する条件を明確にします。これにより、速さと安全性の議論が感覚ではなく evidence に基づく判断へ変わります。

指標とgovernance

Cooldown は設定して終わりではありません。平均 update 時間、critical vulnerability の修正時間、自動 merge 率、失敗 build 数、rollback 回数を追跡します。これらの指標がなければ、policy が risk を減らしたのか、単に queue を遅くしただけなのか判断できません。

小規模teamへの助言

小規模な team は複雑な platform を作る必要はありません。まず default cooldown を使い、重要 package の owner を決め、security alert だけ fast lane にします。次に、PR template に changelog、test 結果、rollback 方法を入れます。これだけでも review 品質は上がります。

Tool選びとの関係

この発表は、開発toolを比べるときに policy 機能を見るべきだと示します。安い tool でも、audit log や severity rule がなければ後で運用 cost が増えます。便利さ、安全性、説明可能性を同時に見てください。