こんにちは。コーポレート本部 サイバーセキュリティ推進部の耿です。
GitHubで管理しているプロジェクトの依存関係（パッケージ）を更新する場合、Dependabot Version Updatesで自動化することがあります。このDependabotについて、以前の記事(GitHub Actions の更新への追随とリスク低減のバランスを考える)で触れたcooldown機能が正式リリースされましたので早速試してみました。
cooldown機能とは
公式発表からの引用です。
The cooldown feature allows you to configure a minimum age requirement before Dependabot creates a pull request for a newly released dependency. This is perfect for folks using version updates with:
・Mature or stable projects that prefer conservative dependency updates.
・High-frequency packages that frequently release updates.
・Teams that want to avoid patch-level noise while staying current.
リポジトリで使用している依存関係（パッケージ）を新しいバージョンに更新するPRをDependabotが作成する際、（リリースからの）経過時間の最小値を設定できる機能です。
想定されているユースケースは以下とのこと。
- 依存関係の更新を保守的に行いたい、成熟したプロジェクトや安定したプロジェクト
- 高い頻度でリリースがあるパッケージを利用している場合
- パッケージを最新の状態を保ちつつ、大量のパッチバージョンの更新によるノイズを減らしたい場合
補足として以前の記事に書いたように、PR作成までに一定期間待機することによって、その間に新バージョンにおけるバグや脆弱性、悪意のある改ざんが検知・解決されることにも期待できます。
機能の詳細
公式ドキュメントおよびベータリリースについて記載されたIssueのコメントを参考にします。（公式ドキュメントがまだ日本語訳されていない場合は英語でご覧ください）
- Dependabotは
dependabot.ymlに設定された更新頻度（schedule.interval）のタイミングで起動します。起動時にcooldownの設定値を考慮し、条件を満たす更新のみPRを作成するという仕組みです。 - Security Updates に cooldownは適用されません。
- cooldown期間を経過したかどうかに関係なく、Version Updatesは脆弱性のあるバージョンに対してはPRを作成しません。
＜例＞更新頻度を日次(daily)、cooldownを3日と設定し、使っているソフトウェアのバージョンが現在 1.1.0 の場合
ケース1：通常のバージョンアップに対する挙動
- 7月1日：バージョン
1.1.1がリリースされる。cooldown期間を経過していないのでPRは作成されない - 7月3日：バージョン
1.1.2がリリースされる。1.1.1も1.1.2もcooldownの期間を経過していないのでPRは作成されない - 7月4日：
1.1.1がcooldownの期間を経過したためPRが作成される。1.1.2はcooldownの期間を経過していないのでPRは作成されない - 7月6日：
1.1.2もcooldownの期間を経過したためPRが作成される。
ケース2：新バージョンに脆弱性が発見された時の挙動
- 7月1日：バージョン
1.1.1がリリースされる。cooldown期間を経過していないのでPRは作成されない - 7月2日：
1.1.1に脆弱性が発見される。cooldownの期間を経過していないのでPRは作成されない - 7月3日：脆弱性を修正した
1.1.2がリリースされる。1.1.1も1.1.2もcooldownの期間を経過していないのでPRは作成されない - 7月4日：
1.1.1がcooldownの期間を経過したが、脆弱性があるためPRは作成されない。1.1.2はcooldownの期間を経過していないのでPRは作成されない - 7月6日：
1.1.2がcooldownの期間を経過したためPRが作成される。
使い方
公式ドキュメントの例を引用します。
dependabot.yml
version: 2 updates: - package-ecosystem: "pip" directory: "/" schedule: interval: "daily" cooldown: default-days: 5 semver-major-days: 30 semver-minor-days: 7 semver-patch-days: 3 include: - "requests" - "numpy" - "pandas*" - "django" exclude: - "pandas"
cooldown のパラメータは全てオプショナルのようですが、少なくとも default-days semver-major-days semver-minor-days semver-patch-days のどれかは記載しないと cooldown の設定として意味を持たないと思われます。
例の設定の場合、
include：requestsnumpydjangoおよびpandasから始まるパッケージ（ワイルドカード*が使用可能）に対して待機時間が設けられます。exclude：pandasに完全一致する名前のパッケージには待機時間が設けられません。semver-major-days： メジャーバージョンアップデートは30日の待機時間が設定されます。semver-minor-days： マイナーバージョンアップデートは7日の待機時間が設定されます。semver-patch-days： パッチバージョンアップデートは3日の待機時間が設定されます。default-days： セマンティックバージョニングをサポートしていないパッケージマネージャ（GitHub ActionsやDockerなど。ドキュメント参照）ではあらゆる種類のアップデートに対して適用される待機時間です。セマンティックバージョニングをサポートしているパッケージマネージャではsemver-major-dayssemver-minor-dayssemver-patch-daysいずれかの記載がない場合、その種類のアップデートにはdefault-daysの待機時間が適用されます。
実際に試してみた
実験用にGitHubリポジトリを作成し、いくつかのnpmパッケージと、GitHub Actionsのサードパーティアクションを利用するように構成しました。
cooldown 機能を利用するために、dependabot.yml は次のように書きました。
dependabot.yml
version: 2 updates: - package-ecosystem: "github-actions" # GitHub Actionsに対する更新ルール directory: "/" schedule: interval: "daily" cooldown: default-days: 3 # 待機期間。検証ではすぐに結果を知りたいので3日にしてみます - package-ecosystem: "npm" # npm に対する更新ルール directory: "/" schedule: interval: "daily" cooldown: default-days: 3 # 待機期間
npmパッケージの更新
cdk-nag というパッケージの v2.36.30 は 2025/6/30 9:16 にリリースされましたが、DependabotがPRを作成したのは 2025/7/3 21:59 でした。
cooldownを設定していない時はリリースから1日以内にPRが作成されていたので、ちゃんとcooldownが効いていることがわかります。
GitHub Actions の actionの更新
GitHub Actions の actionの更新でも同じことを確認できました。
電通総研が公開しているサードパーティアクション dentsusoken/build-and-scan-image （コンテナイメージに対するhadolint、dockle、trivyによるスキャンを一括で実行できるaction）をコミットハッシュ（SHA）でバージョン指定し、ワークフローを作成しています。
デフォルトブランチに新しいコミット 990b445 は2025/6/30 9:43 にプッシュされましたが、DependabotがPRを作成したのは 2025/7/3 21:55でした。
まとめ
以前の記事でも触れたとおり、GitHub Actions については push など特定のイベントトリガーを使うと、更新されたブランチ（更新された新しいバージョン）のワークフローファイルが実行されます。新しいバージョンに悪意のあるコードが含まれていた場合、 PR が自動作成されただけで悪意のあるコードが自分のリポジトリ上で実行される可能性があるため、cooldown機能を使って一定期間はそもそもPR自体を作成しないことは、GitHub Actionsが侵害された場合に対する防御として有効だと考えられます。
Dependabot Version Updatesを使っている場合は、セキュリティの観点でもぜひ cooldown 機能の使用を検討してみてください。
私たちは一緒に働いてくれる仲間を募集しています！
電通総研 キャリア採用サイト執筆：@kou.kinyo
レビュー：Ishizawa Kento (@kent)
（Shodoで執筆されました）
