結論：3日は「観察時間」であり、packageの安全証明ではない
GitHubは2026年7月14日、Dependabot version updatesが、registryで公開された新releaseについて最低3日待ってからPull Requestを作るpackage cooldownを既定にしたと発表しました。設定不要で適用されます。
新release直後は、maintainerやcommunityが侵害・不具合を発見する前に悪意あるversionを取り込むsoftware supply chain riskがあります。短い待機時間はsignalが表面化する余地を作ります。
ただし重要な限定条件があります。
- 既定の3日cooldownはversion updatesだけ
- security updatesは即時に開かれ、critical fixを遅らせない
.github/dependabot.ymlのcooldownで期間変更・opt-outが可能- github.comの全supported ecosystemが対象で、GitHub Enterprise Serverは3.23から
この記事は、SaaS・Web serviceを運営する経営者、CTO、開発責任者、発注者向けです。作る相談はDependabot設定代行ではなく、依存package台帳、risk tier、緊急更新、回帰test、rollbackを設計するsupply-chain診断です。
FREE CONSULTATION
この記事の内容について、専門家に相談できます
AI・DX・セキュリティに関するご質問やお見積もりなど、お気軽にお問い合わせください。
3日cooldownで解決すること・しないこと
横にスクロールして確認できます
| 項目 | 助けること | 別途必要なこと |
|---|---|---|
| 新release直後 | 即時追随を避け、community signalを待つ | publisher、署名、変更、評判、advisory確認 |
| version update | PR作成を遅らせる | CI、review、staging、rollback |
| security update | 既定cooldownの対象外で即時 | 悪用・露出・互換性による緊急順序 |
| package別運用 | 設定で日数・include・excludeを調整 | business criticalityとownerの定義 |
GitHub Docsではcooldown日数を1〜90日で設定でき、default、SemVer major/minor/patch、include/excludeを調整できるとしています。supported package managerによってSemVer別設定の対応は異なります。
Cooldown導入で起きる5つの失敗
- 3日経過を安全承認にする。 悪意あるcodeや重大bugが4日目以降に発覚する可能性があります。
- security updateも3日遅れると誤解する。 緊急CVE対応のSLAと運用が混乱します。
- 全packageを同じ日数にする。 認証・暗号・build actionと開発toolのrisk差が消えます。
- PRが来たら自動mergeする。 lockfile、transitive dependency、install script、maintainer変更を見ません。
- 待ちすぎて保守負債を作る。 大量の差分をまとめて上げ、原因特定とrollbackが難しくなります。
FREE DOWNLOAD
AI導入チェックリスト（PoC 失敗要因 10項目）
情シス部門が PoC 前に押さえるべき失敗要因を10項目に整理した無料チェックリスト。
GXO式「Package update 5ゲート100点」
横にスクロールして確認できます
| ゲート | 配点 | 満点の証拠 | レッドフラグ |
|---|---|---|---|
| 依存・owner | 20 | direct/transitive、runtime/build、owner、利用箇所、SBOMを把握 | lockfileだけ |
| risk tier | 20 | 認証、network、install script、privilege、重要業務でtier化 | 全package 3日 |
| cooldown・例外 | 20 | major/minor/patch、include/exclude、security SLA、緊急承認を定義 | opt-outが無承認 |
| test・rollback | 25 | CI、security、staging、canary、lockfile、旧version復帰を試験 | green buildだけ |
| 証拠・改善 | 15 | release、advisory、review、merge、incident、遅延、再発を記録 | PR件数を成果にする |
合計点に関係なくmergeを止める条件
- publisher・repository・ownershipに不審な変更がある
- install script、GitHub Actions、build pluginが新たな外部通信・secret accessを要求
- lockfileに意図しないpackage・registry・hash変更がある
- 重大業務の回帰test・rollbackがない
- security updateを通常version updateと誤分類し、緊急性を判断できない
仮想記入例：決済SaaSのnpm依存更新
横にスクロールして確認できます
| ゲート | 得点 | 不足 |
|---|---|---|
| 依存・owner | 15/20 | transitiveの決済SDK補助packageを未分類 |
| risk tier | 11/20 | runtimeとtest toolが同じ3日 |
| cooldown・例外 | 12/20 | security updateの24時間SLAがない |
| test・rollback | 13/25 | unit testのみ、決済sandboxとcanaryなし |
| 証拠・改善 | 8/15 | maintainer・release provenance未確認 |
| 合計 | 59/100 | 自動mergeを止め、risk tierを再設定 |
認証、決済、GitHub Actions、install scriptを高risk tierへ分けます。通常versionは観察時間を設け、security updateは悪用・露出を確認して即時testします。stagingと少数canaryで監視し、lockfileを含め旧versionへ戻せるようにします。
設定例はpolicyと一緒に管理する
cooldown:
default-days: 5
semver-major-days: 30
semver-minor-days: 7
semver-patch-days: 3
exclude:
- "company-emergency-package"
この例はGitHub公式の設定項目を使った説明用です。excludeは待機から外れて即時update対象になるため、package名だけでなく、例外理由、owner、security SLA、必要testをpolicyへ記録します。実際のsupported optionはpackage ecosystemごとに公式Docsで確認してください。
開発会社へ確認する10問
- direct・transitive dependencyのownerは誰か
- runtime、build、GitHub Actions、testをrisk別に分けたか
- 既定3日を変更・解除する承認者は誰か
- security updateがcooldown対象外であることを運用へ反映したか
- publisher・maintainer・repository変更を確認するか
- install scriptとsecret accessをreviewするか
- lockfile・hash・registry差分を検査するか
- staging・canary・rollbackをどこまで行うか
- SBOMと納品versionを発注者へ引き渡すか
- package incident時の停止・rotation・顧客通知手順はあるか
GXOのDevSecOps支援では、SBOM、Dependabot、CI/CD、review、例外、rollbackを一体で診断します。既存systemの依存riskは脆弱性診断、外注開発の納品・保守条件はシステム開発セカンドオピニオンへ接続します。
FAQ
3日待てばsupply chain attackを防げますか
保証はできません。発見signalを待つ時間を作るcontrolです。provenance、review、test、最小権限、監視、rollbackと組み合わせます。
security patchも3日遅れますか
GitHubの発表では、既定cooldownはversion updatesだけで、security updatesは即時に開きます。
全packageを30日待つ方が安全ですか
更新遅延による脆弱性・互換性・保守負債も増えます。packageの権限、用途、変更種別、緊急性で日数を分けます。
出典・確認日
- GitHub「Dependabot version updates introduce default package cooldown」（2026年7月14日発表、2026年7月15日確認）
- GitHub Docs「Dependabot options reference - cooldown」（2026年7月15日確認）
- GitHub Docs「Optimizing the creation of pull requests for Dependabot version updates」（2026年7月15日確認）
既定値、supported ecosystem、GHES version、設定optionは変更される可能性があります。最新のGitHub公式文書と自社configurationを確認してください。cooldownはpackageの安全性を保証しません。本記事の配点・仮想例・YAMLの例外名はGXO独自です。
