Dependabot's 72-hour wait and PyPI's 14-day file lock: what they stop

Two of the most widely used pieces of package-ecosystem infrastructure have changed in response to the recent wave of malicious npm and PyPI releases. Both changes work by adding delay, not by adding detection.

What changed

Dependabot now has a default cooldown of three days (72 hours). When a new version is published to a registry, Dependabot waits at least that long before opening a pull request to adopt it in a repository it monitors. The interval is configurable, so teams can make it shorter or longer depending on how aggressively they want to take upgrades.

PyPI now stops maintainers adding new files to a release once 14 days have passed since it was published. The aim is to stop an attacker who has stolen a publishing token, or who controls a publishing workflow, from slipping a malicious file into an old release that users already trust.

Why time is the lever

The Dependabot rationale rests on a recurring pattern. Security tooling often flags a malicious package within minutes of publication. Removal and downstream notification take longer. A cooldown on automatic updates gives the ecosystem time to act on those early signals before an automated pull request pulls the package into your build.

The PyPI change addresses a different attack shape. A compromised token used to be enough to add a poisoned wheel to a long-standing version, which existing pins would then install. Locking old releases removes that option after two weeks, and a new malicious release has to be a new version, which is more visible.

What it does not cover

• Manual installs and unpinned dependencies. A cooldown on Dependabot pull requests does nothing for pip install or npm install run directly against the latest version.
• Slow-burn compromises. A malicious version that goes unflagged for longer than the cooldown still gets proposed.
• Attacks inside the 14-day PyPI window. The lock applies after 14 days, so file additions inside that period remain possible.
• Other ecosystems and registries. These are two specific controls, not a general guarantee.

What to do with this

1. 1Check the Dependabot cooldown against your own risk tolerance. Set it explicitly instead of relying on the default, and decide whether security updates need a different policy from routine version bumps.
2. 2Pin dependencies and verify hashes in CI so an altered artifact fails the build.
3. 3Restrict and rotate publishing credentials, and prefer short-lived, scoped tokens for release workflows.
4. 4Monitor advisories and takedown feeds so that the cooldown period is used for review and not just waiting.

These are sensible defaults that raise the cost of opportunistic poisoning. Treat them as one layer in a build pipeline that still assumes some upstream packages will be malicious.