标签：#dependabot

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