⏳ Dependabotの既定クールダウン: 待つことを既定にした判断と、その境界

GitHub は 2026-07-14 から、Dependabot の version updates に既定 3 日のクールダウンを適用しました。新しいリリースが公開されてから 3 日間は、更新 PR が出ません。設定は不要で、全ユーザーに適用されます。

この変更で新しく増えた機能はありません。同じ機能は 2025-07-01 に "minimum package age" の名で GA しています。変わったのは、待つ状態と待たない状態のどちらを初期状態に置くかという一点です。

本記事では、この既定値の変更が何を保証して何を保証しないのかを、公式ドキュメントと dependabot-core の実装、および実インシデントのタイムラインから整理します。想定読者は、依存更新の自動化ポリシーを決める立場の方です。結論を先に 3 点挙げます。

1. 3 日は合理的な下限です。ただし上限でも万能でもありません
2. 「security updates は遅れない」は条件付きでしか成立しません
3. 待機は継承されるのに、免除は継承されません

変更の概要

仕様の骨格

既定値の 3 日は、dependabot-core の DEFAULT_COOLDOWN_DAYS = 3 と一致します。

設定キーは 6 つ

dependabot.yml の cooldown ブロックで指定できるキーは 6 つです。dependabot-core の cooldown_definition.rb のキー名と完全に一致します。

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    cooldown:
      default-days: 3
      semver-major-days: 7
      exclude:
        - "@my-org/*"

完全に無効化する指定は公式内で矛盾しています

無効化の指定値について、公式内で記述が割れています。

dependabot-core の実装は 3 段階すべてで 0 を生存させ、within_cooldown_period? は cooldown_days <= 0 で false を返します。つまり core は 0 を完全な opt-out として正しく処理します。ただし dependabot.yml の構文バリデーションは GitHub 側の非公開実装であり、0 が受理されるかまでは確認できませんでした。

仕様上ぶれない代替は exclude: ["*"] です。File.fnmatch? による全一致で、exclude は常に include より優先されます。

「3 日の起点」も表現が揺れています

同じ機能の説明が、ソースによって次のように異なります。

実装は公開時刻ベースですが、正式な定義は一次情報で確定できませんでした。通常は差が問題になりません。公開とレジストリ反映に時間差があるミラー構成では、意味が変わりえます。

grouped updates はグループ全体を待ちません

公式ドキュメントに記述がないため、実装で確認しました。

クールダウンはグループ単位のゲートではなく、依存ごとの候補バージョン一覧に対するフィルタとして効きます。GroupUpdateCreation#update_checker_for はグループのメンバー 1 件ずつに update checker を生成し、update_cooldown: job.security_updates_only? ? nil : job.cooldown を渡すだけです。グループ経路と単体経路でこの行は完全に同一で、「グループだから待つ」という分岐はコード上に存在しません。

結果は 2 通りに分かれます。

• 新しいリリースが全部クールダウン中: 現行版のみが候補になり、そのパッケージはグループ PR から落ちる
• 中間リリースがクールダウンを抜けている: より小さい bump としてグループ PR に載る

「グループから除外される」は前者の結果論であり、仕様として保証されたものではありません。公式ドキュメントに記述がない点は未確定として扱ってください。

免除を決めるのは「修正かどうか」ではありません

分岐の構造

免除の可否を決めるのは、そのリリースが修正かどうかではありません。advisory に登録済みかどうかです。脆弱性修正であっても、advisory 登録前は version update 経路を通り、既定 3 日の待機対象になります。

公式ドキュメントの記述で前提が閉じます

GitHub の changelog は "Security updates still open immediately, so critical fixes are never delayed" と書いています。Dependabot 自身の挙動としてはそのとおりです。この保証は、脆弱性が advisory として登録済みであることを前提にしています。

公式ドキュメントの記述を連鎖させると、前提が明示的に条件付きであるとわかります。

1. security update の引き金は alert です

"If you enable Dependabot security updates, when a Dependabot alert is raised for a vulnerable dependency in the dependency graph of your repository, Dependabot automatically tries to fix it."

2. alert の引き金は advisory 登録です

"A new vulnerability is added to the GitHub Advisory Database"

3. 登録されるのはレビュー済みのものだけです

"Only advisories reviewed by GitHub trigger alerts."

4. 登録には時間がかかりえます

"New vulnerabilities may take time to appear in the GitHub Advisory Database and trigger alerts."

メンテナが脆弱性を修正したリリースを出しても、advisory が登録されるまでの間、その修正版は Dependabot にとって通常の新しいバージョンです。version update 経路を通り、既定 3 日のクールダウンの対象になります。

この構造は実装の不具合ではなく、設計に内在します。正確な理解は「クールダウンは security fix を遅らせない」ではなく、「advisory として認識された security fix を遅らせない」です。

実務で効いてくるのは次の 2 ケースです。

• メンテナが CVE 化せず、通常リリースとして脆弱性を修正する慣行
• 公表から advisory 登録までにラグがある大規模インシデントの初動

advisory 登録ラグの定量データは、一次・二次とも見つかりませんでした。どれくらい遅れるかは本調査では答えられません。構造として存在することのみが確認できています。

待機を強制する 3 つの層

「security updates は免除」という記述がどこまで保証されるかは、待機がどの層で発生するかによって変わります。

層 2 の現状

dependabot-core の実装で確認した、2026-07-24 時点の状況です。

uv は dependabot-core 全体を exclude-newer および exclude_newer で検索して 0 件でした。Uv::FileUpdater::LockFileUpdater#run_update_command が組む uv lock にも上書き分岐がありません。

ただし uv の exclude-newer は絶対日時カットオフであり、他の「N 日ローリング age gate」とは意味論が異なります。主用途は再現性ビルドです。この差は割り引いて読んでください。

層 2 の状況は週単位で変化します。Bundler の修正は本調査日の 7 日前です。恒久的な論点は層 2 ではなく、advisory 登録ラグと層 3 にあります。

層 3 には緊急バイパスが設計されていません

層 3 は利用者自身が置いた待機であり、Dependabot の免除は届きません。公式に実害が明記されているのは npm audit fix の経路です。

npm keeps the package at its vulnerable version, warns that the fix was blocked, and exits with a non-zero code

min-release-age を長く設定していると、npm audit fix が脆弱版を維持したまま非ゼロ終了します。npm 側には min-release-age-exclude という公式の逃げ道がありますが、設定していなければ塞がったままです。

より厳しいのは、レジストリ前段の検疫プロキシです。日本語圏の実務記事には、Nexus の前段に自作プロキシを置き、公開後 14 日以内のパッケージを 403 で拒否する構成があります。この層は lockfile の pin も security 判定も無関係に拒否します。緊急時のバイパス手段を自分で設計していなければ、脆弱性修正の取り込み自体が止まります。自作である以上、バイパスも自作するしかありません。

なお npm ci が既存 pin の security fix を弾く経路は確認できませんでした。min-release-age は解決時フィルタであり、lockfile 使用時は manifest 解決自体が走らないためです。ただしこれを明記した公式文は見つかっていません。実装からの推論として扱ってください。

3 日という値は妥当か

公式は 3 日の定量的な根拠を示していません。実データで検証します。

母集団を分けないと必ず誤読します

クールダウンが効くのは、既に依存しているパッケージの悪意ある新バージョンだけです。この区別を落とすと、正反対の結論が出ます。

学術データセットはいずれも前者を測っています。Duan et al. の NDSS 2021 は 20% が 400 日超滞留、Guo et al. の ASE 2023 は潜伏 2 ヶ月超が 28% と報告しています。これらを根拠に「3 日では全く足りない」と結論するのは、母集団の取り違えです。逆に、後者だけを見て「クールダウンで大半を防げる」と一般化するのも誤りになります。

実インシデントの発覚時刻は二峰性を示します

npm registry API のミリ秒精度タイムスタンプと OSV / GHSA を突き合わせて構築したタイムライン、n=14 の結果です。

代表的な発覚までの時間は、debug 4.4.2 が 1 時間 14 分、rc が 54 分、Nx が 4 時間 12 分、axios 1.14.1 が 2 時間 54 分でした。

分布は数時間と数十日に割れており、その間が空いています。この形が意味するのは次の 2 点です。

1. 3 日は高速検知クラスタを捕捉するのに十分です
2. 3 日を 7 日に延ばしても、観測範囲での追加効果はほぼありません。1〜7 日帯に事例がないためです

「10 件中 8 件は 1 週間以内」の扱いに注意します

日本語圏で繰り返し引用される「悪意あるパッケージ 10 件中 8 件は 1 週間以内に検出・削除」という数値は、原典が William Woodruff のブログ記事、2025-11-21 です。

母集団は n = 10 で、著者が過去 18 ヶ月の著名事例を手で選んだ便宜標本です。原典には次の但し書きが実在します。

"In the very small sample set above, 8/10 attacks had windows of opportunity of less than a week."

統計的推定ではなく事例集です。この数値を「一般に 8 割が 1 週間以内」と読むのは過大解釈になります。原典の表を 3 日で切り直すと、3 日未満 7 件、ちょうど 3 日 1 件、3 日超 2 件です。7 日との差は約 1 件にとどまります。

さらに、原典が 7 日推奨の根拠に挙げる事例のうち tj-actions はタグ改竄です。バージョン更新が発生しないため、クールダウンの保護はゼロです。NVD の CVE-2025-30066 には "modified by a threat actor to point at commit 0e58ed8" と一次記載があります。対策は SHA ピン留めであり、待機ではありません。

合理的な下限であり、上限ではありません

直接依存にクールダウンをかけても、間接依存は当時の最新を引きます。

3 日を「安全になった」と読むのではなく、「自動取り込みから短命な汚染版を外す下限が既定になった」と読むのが正確です。

待機は継承されるのに、免除は継承されません

GitHub 公式 blog は次の調整を推奨しています。

"If you'd like to customize your delay for highly trusted internal packages versus public registries, check out the documentation on configuring Dependabot."

内部パッケージと公開レジストリで待機を変えることは、GitHub 自身が想定するユースケースです。ところが実装には非対称性があります。

.npmrc に両方を書いても、制約だけが Dependabot に継承され、緩和は継承されません。Dependabot 側で除外するには dependabot.yml の cooldown.exclude を別途書く必要があり、同じ意図の除外を 2 箇所で二重管理することになります。

この要求は日英で独立に表面化しています。

公式が推奨するユースケースに、公式の実装が片方の経路で追いついていない状態です。

この非対称性は運用ルールにも波及します。既定化の翌日に公開された日本語記事は、default-days: 0 や semver-patch-days: 0 や exclude を「既定 3 日を壊す設定」として CI で検査するスクリプトを提案しています。しかし cooldown.exclude は、信頼する自社パッケージを外す唯一の手段でもあります。検査するなら「exclude の有無」ではなく、「除外対象が信頼境界の内側かどうか」を見るべきです。

他実装との比較

同じ「新しいリリースをすぐ採用しない」制御は、他のツールにも実装されています。既定で有効かどうかはツール間で割れています。

設計上の差で重要なのは次の 3 点です。

1. セキュリティ更新の扱いが正反対のものがあります。Renovate はクールダウンをバイパスして即 PR を出し、npm は逆に npm audit fix をブロックします。同じ待機でも、緊急経路の有無で安全性の意味が変わります
2. 全ツールが取得日時ではなく、レジストリ公開時刻を基準にします。したがって「いつ気づいたか」ではなく「いつ世に出たか」で待機が決まります
3. タイムスタンプが取れないときの挙動が割れます。fail closed は Renovate 42 以降と uv、fail open は pnpm と Bun です。後者は「待機しているつもりで待機していない」状態を作りえます

「npm 本体に相当機能はない」という説明は誤りです。npm CLI 11.10.0、2026-02-11 で追加済みです。

反証と、それでも残る強度

本記事の結論を否定する側のエビデンスを、専任で探索した結果です。

揺らいだ論点

反証が見つからなかった論点

• 「クールダウンは無意味」を支える定量的反証は皆無でした。批判的な論者も "it raises the bar" は認めています
• 既定化そのものへの反対は、GitHub の事前 Poll で「即時 PR を続けてほしい」が 0 票でした。ただし総投票数は 3 票にすぎず、選好の分布を語れる標本ではありません。「反対が観測されなかった」以上の主張はできません
• ロールアウト後 10 日の公開チャネルに、「遅くなって壊れた」という実害報告が見つかりませんでした。むしろ観測されたのは「maven で 11 時間後に PR が来た、つまりクールダウンが効いていない」という逆向きの苦情でした。GitHub と Hacker News の範囲での所見です
• 攻撃者の適応、つまり待機期間をやり過ごしてから発火する手口は理論的主張のみで、実例はゼロでした。ただし不在の証明ではありません

免除の方針自体は否定されていません

層 2 で見つかった穴はすべて実装漏れであり、方針の否定ではありません。PR #15485 は設計思想を明文化しています。

"Security updates are never gated — they still pass the existing =0 bypass (which intentionally overrides any native gate)."

問題は方針ではなく、その方針がどこまで届くかの境界にあります。

未解決の問い

実務への落とし込み

設定を見直す観点を 6 つ挙げます。

1. 既定 3 日をそのまま受け入れてよいか
   短命な汚染版を外す下限としては妥当です。7 日に延ばしても、観測範囲での追加効果は薄いままです。延ばすなら「何を防ぎたいのか」を長期潜伏型と切り分けてから決めます
2. 内部パッケージを除外するなら dependabot.yml に書く
   .npmrc の min-release-age-exclude は Dependabot に届きません。cooldown.exclude が必要で、二重管理になることを前提に運用します
3. 層 3 に緊急バイパスを設計しているか
   検疫プロキシや CI の age gate には、Dependabot の免除が届きません。「脆弱性修正のときだけ待機を外す」経路を、待機を作ったのと同じ人が設計します
4. npm audit fix が非ゼロ終了する構成になっていないか
   min-release-age を長く設定している場合、min-release-age-exclude の設定を確認します
5. CI 検査を入れるなら信頼境界で判定する
   exclude の有無ではなく、除外対象が信頼境界の内側かどうかを見ます。exclude 自体は公式が推奨する調整手段でもあります
6. uv を使っている場合は層 2 の残存ギャップを意識する

公的機関のガイダンスとも整合します。内閣官房 国家サイバー統括室のガイドライン、令和 8 年 6 月 12 日一部改定は、「迅速な適用の要否を判断した上で」脆弱性対策計画を策定・実施することを求めています。一律即時でも一律待機でもなく、要否を判断するプロセスを運用設計に組み込む構造です。security と version で経路を分ける設計は、これと整合します。

依存更新を SHA pin や lockfile や vendoring を含む多層で固める全体構造は、CI/CD依存をロックダウンする で扱っています。本記事はその再説をせず、待機時間が既定値になったこと自体の意味に絞りました。

まとめ

Dependabot の既定クールダウンは、待つか待たないかの初期状態を反転させた変更であり、3 日は短命な汚染版を自動取り込みから外すための合理的な下限です。ただし免除の可否を決めるのは advisory への登録有無であり、待機は継承されるのに免除は継承されないという非対称性が残るため、緊急経路を自分で設計しているかどうかが実務上の分かれ目になります。

この記事が少しでも参考になった、あるいは改善点などがあれば、ぜひリアクションやコメント、SNSでのシェアをいただけると励みになります！

参考リンク

• GitHub 公式
  • The case for a cooldown: why Dependabot now waits before issuing version updates
  • Dependabot options reference
  • About Dependabot alerts
  • About Dependabot security updates
  • GitHub Changelog
• GitHub
  • dependabot-core Discussion #15368 - cooldown defaults
  • dependabot-core Issue #15157 - Support age/cooldown controls
  • dependabot-core Issue #15348 - honour min-release-age-exclude
  • dependabot-core Issue #15407 - Bundler native cooldown blocks security updates
  • dependabot-core PR #15132
  • dependabot-core PR #15485
  • dependabot-core PR #15517
• 他実装のドキュメント
  • Renovate: minimumReleaseAge
  • pnpm: settings
  • Yarn: npmMinimalAgeGate
  • npm: min-release-age
• 記事
  • We should all be using dependency cooldowns
  • CI/CD依存をロックダウンする