GitHub's Dependabot Now Waits 72 Hours Before Updating Your Dependencies

Dependabot just got noticeably more paranoid about fresh releases. GitHub has flipped on a default three-day cooldown for non-security version update pull requests, so a brand-new package version has to sit in its registry for at least 72 hours before Dependabot will suggest bumping to it. Security updates for known CVEs still fire off immediately.

The change targets a supply chain attack pattern that has become depressingly common: an attacker pushes a poisoned release of a popular package, automated update tooling grabs it within minutes, and the malicious code hits build pipelines before anyone notices. A short waiting period gives scanners, maintainers, and the community a chance to catch and pull the bad version first.

The npm incident that made the case

GitHub's blog post opens with a concrete example. In September 2025, an attacker phished credentials from a single npm maintainer and published trojanized versions of chalk, debug, and roughly a dozen other packages collectively downloaded more than 2 billion times weekly. The malicious code rewrote cryptocurrency wallet addresses inside any browser application that loaded it. The poisoned versions were live for roughly two hours before the community caught them and npm pulled them.

Two hours is a fast community response, but it is more than enough time for an aggressive auto-updater to open a PR against your repo. The pattern also is not a one-off. In the year ending May 2026, the GitHub Advisory Database published more than 6,500 npm malware advisories, up from roughly 6,200 the year before, which adds up to approximately 18 newly cataloged malicious packages every day.

Why three days is the sweet spot

GitHub cites an external review of 21 well-known supply chain incidents between 2018 and 2026 showing that malicious versions of packages like axios, Solana web3.js, ua-parser-js, and Ledger Connect Kit were each caught within hours of publication. "Three days as the default balances two goals: it pushes you past the window where most of these attacks live, and it doesn't hold your dependencies back longer than necessary," the team wrote. It also happens to match what several other package management tools have converged on, so behavior stays consistent as developers move between ecosystems.

What actually changed and how to tune it

The rollout is a new default rather than a new feature. Dependabot now waits until a release has been available on its registry for at least three days before opening a version update pull request. No configuration is required. The default applies to Dependabot version updates across all supported ecosystems on github.com and will take effect in GitHub Enterprise Server (GHES) 3.23.

The cooldown block in .github/dependabot.yml remains the knob for tuning behavior. A few useful patterns:

• Keep the default: do nothing, you get three days automatically.
• Longer window for public registries: set a bigger default-days value on ecosystems like npm or PyPI.
• Faster updates for trusted internal packages: scope a shorter cooldown to specific dependency patterns via include/exclude.
• Opt out entirely: set default-days: 0.

A minimal config that removes the delay looks like this:

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "daily"
    cooldown:
      default-days: 0

The full parameter set lives in the Dependabot options reference, which also confirms that the cooldown option is only available for version updates, not security updates.

Where a cooldown falls short

GitHub is upfront that this is defense in depth rather than a silver bullet. A cooldown only helps against the fast-moving, get-caught-quickly attack shape. It does nothing against backdoors planted quietly and left dormant, maintainer sabotage that goes unnoticed for weeks, or compromised build systems that ship signed but malicious artifacts.

There is also a subtle critique of the model itself. In response, user woodruffw argued that the security model behind cooldowns does not rely on end users encountering malicious packages, but on dedicated security scanning efforts: "the security assumption behind cooldowns rests on security scanning parties, not on innocent users being victimized". The cooldown works because somebody else is playing canary, so pairing it with your own scanning and review still matters.

For anyone running Dependabot, the practical takeaway is that the safer default is now free, and if the extra latency bothers you on internal packages, the config surface is granular enough to carve out exceptions without giving up protection on the public registries where the real risk lives.