标签：#Dependabot

A new default three-day cooldown delays version update pull requests so maintainers and security researchers can address findings in a release before it gets into your code. The post The case for a cooldown: Why Dependabot now waits before issuing version updates appeared first on The GitHub Blog .

GitHub announced on July 14, 2026 that Dependabot now waits until a release has been available on its registry for at least three days before opening a version-update pull request. The cooldown is the new default and requires no configuration. Primary source: GitHub Changelog, July 14, 2026 . The product question is not whether three days is universally safer. Waiting may expose a broken or compromised release before adoption, but it can also postpone a needed compatibility fix. Cooldown is a baseline, not a complete dependency policy. Separate normal freshness from security response release -> cooldown -> update PR -> CI -> review -> deploy -> observe A cooldown does not replace lockfiles, CI, provenance checks, staged deployment, or rollback. It should not silently delay an urgent security-update workflow either. Use this decision table before creating exceptions: Package situation Suggested decision Compensating control Routine dev dependency with strong CI Keep default Deterministic tests Runtime package on a critical path Keep or lengthen Canary and fast rollback Identified security remediation Use the dedicated urgent path Security owner and targeted tests Isolated build-only tool Consider shorter Reproducible artifact checks Volatile pre-1.0 package Consider longer Manual release review Internal package released with the app Consider exception Exact-version integration test Parser, auth, crypto, or installer Keep default unless urgency wins Sandbox and abuse fixtures Score the exception Rate each dimension from 1 to 5: blast radius; upstream release volatility; test strength; rollback speed; cost of waiting. Then use two conversation scores: wait_value = blast_radius + release_volatility ship_confidence = test_strength + rollback_speed + cost_of_waiting This is not a statistical risk model. It forces the team to name evidence. Keep the default when scores are close. Consider shortening only when delivery evidence clearly exceeds wait value. Route vulnerabilit

Every time your bot merges a two-hour-old release into main, you are trusting a stranger's freshly published tarball to be the same one everyone else is looking at. Sometimes that release is a real bugfix. Sometimes it is a maintainer who fat-fingered a token, or an attacker who did not, and either way your CI cheerfully rebases against it before anyone had a chance to notice. On 2026-07-14, GitHub added a pause. Not a big one. But a real one. The actual change Dependabot version updates now sit on their hands for three days after a package is published. According to the GitHub Changelog, a release has to have been available on its registry for at least that long before Dependabot will open a version-update pull request against your repository. The cooldown is on by default and requires no configuration. It applies across every ecosystem Dependabot supports on github.com, and GitHub Enterprise Server picks it up in GHES 3.23. Security updates are exempt. If a fix for a known vulnerability lands, Dependabot will still open the PR the moment it can, because a three-day delay on the patch defeats the entire point of shipping the patch. That single carve-out is the whole design. Why three days is doing so much work Three days is not enough time to audit a package. Nobody is pretending otherwise. What three days is enough for is someone else to notice. Most malicious releases that end up on a public registry get pulled quickly once security researchers, downstream maintainers, or the registry's own scanners spot the pattern. The typosquats, the hijacked accounts, the crypto miners buried in a postinstall script: they all rely on being pulled into build automation before the pattern is visible. Dependabot's old default was to be that automation. Its new default is to let the pattern show up first. You can read this change as GitHub quietly admitting that "always up to date" was the wrong marketing promise for a supply-chain tool. The knob, and what shifted about it Cooldo

The first time I wired Dependabot up to a private package registry, it took three meetings and a calendar reminder set six months ahead. The reminder was for the personal access token I had to mint to do it, the one I would have to rotate by hand before it expired, living in a config that drifted somewhere between repo settings, a .github file, and an internal wiki page nobody had touched in a year. On June 23 GitHub posted a small changelog item that quietly retires that whole ritual: Dependabot can now read your private GitHub Packages and GHCR registries through its own GITHUB_TOKEN , no PAT required. If you have ever had to explain to a security review why your bot account holds a token your team owns but a person minted, you already know why this lands. The PAT we all had and nobody loved Until this week, Dependabot's path to a private GitHub-hosted package was the same path it took years ago. A human minted a personal access token, scoped wide enough to read the registry, stored it as a repo or org secret, and plugged it into Dependabot so the bot could authenticate when it tried to resolve dependencies. That token expired on a human schedule. It belonged to whoever happened to set Dependabot up, which is rarely the person who still owns the repo a year later. You can feel how that ends. Tokens that quietly expire and break a Dependabot PR the day someone needs the patch. Tokens that follow an offboarded engineer out the door. Tokens with scopes wider than the job actually requires, because nobody wanted to mint a fine-grained one per registry path. None of those failures are catastrophic on their own. All of them are the kind of papercut a platform team ends up owning. What the GITHUB_TOKEN does here The new behavior is straightforward. Dependabot's job-scoped GITHUB_TOKEN can now request a packages: read permission. When the bot pulls from a hostname under *.pkg.github.com or ghcr.io , it sends that token instead of asking for a PAT. The same token that alre