Wait Before You Update: The 72-Hour Software Supply-Chain Rule Founders Need

01Executive summary

• GitHub now waits three days before Dependabot opens a routine version-update pull request. Security updates are not delayed.
• PyPI now rejects new files added to releases older than 14 days, reducing the chance that an established version can be quietly poisoned later.
• The recent AsyncAPI compromise showed how trusted publishing automation can distribute malicious code at high speed.
• A cooldown reduces exposure to fast-detected attacks, but it does not replace version locks, scanning, testing, provenance, and controlled release permissions.
• Founders should establish one default wait, one documented exception path, and one accountable owner for dependency risk.

02What GitHub and PyPI changed

GitHub's July 14 update made a three-day cooldown the default for Dependabot version updates across supported ecosystems on GitHub.com. A new version must be available on its registry for at least three days before Dependabot proposes it.

The exception matters: Dependabot security updates still open immediately. Teams can also tune the routine window from one to 90 days and use different delays for major, minor, and patch releases. This is not a blanket instruction to patch slowly. It separates maintenance from remediation.

PyPI added a different control on the publishing side. Its July 22 announcement says new files can no longer be uploaded to releases older than 14 days. If maintainers need another file, they must publish a new version. That makes a changed artifact visible instead of silently altering a release buyers may already trust.

03Why three days can matter

The dangerous period begins when a compromised release appears and ends when the registry or community identifies it. Automated builds compress adoption into that same window. GitHub's analysis of past incidents found that malicious releases of packages including axios, Solana web3.js, ua-parser-js, and Ledger Connect Kit were removed within hours.

A 72-hour wait moves a routine update beyond that first high-risk period. It gives maintainers, registries, researchers, scanners, and other adopters time to create evidence your release process can use.

The business impact is straightforward. Avoiding one compromised update can prevent credential rotation, emergency rebuilds, customer notifications, forensic work, downtime, and a difficult trust conversation with buyers. The cost of waiting three days for a routine feature or patch is usually much smaller.

04The AsyncAPI compromise is the real example

On July 14, attackers compromised the release process for four AsyncAPI npm packages and published five malicious versions. Datadog reported that the affected package group had more than three million weekly downloads. Legitimate publishing infrastructure made the bad releases look like normal automated output.

Microsoft's investigation found that the malicious code ran when software imported the package, rather than through a conventional install script. A team relying only on blocking install scripts could still have been exposed.

A dependency cooldown would not have repaired the compromised project. It would, however, have kept workflows that respected the delay on the previous known version while responders investigated and removed the malicious releases. That is the value of the control: it reduces your exposure without requiring your company to discover the attack first.

05Adopt a five-part dependency policy

1. Wait by default. Start with 72 hours for routine version updates. Use longer windows for major changes to critical systems when the business can tolerate them.
2. Fast-track verified security fixes. Confirm the advisory, affected versions, and source of the fix. Do not let a routine queue delay a known vulnerability response.
3. Lock production versions. Builds should use reviewed, repeatable versions rather than silently selecting whatever is newest at deployment time.
4. Test the full change. Review direct and indirect dependencies, run automated checks, compare the package contents, and test the customer journeys that create revenue or operational risk.
5. Make exceptions visible. Name who can bypass the cooldown, what evidence is required, and how the decision is recorded. An urgent feature request is not automatically an emergency.

A small SaaS team can begin with one policy in its source-control system and one release checklist. A larger company may need shared rules across repositories, a software inventory, and ownership by product area. The principle remains the same: default automation should express the company's risk decision.

06Know what a cooldown cannot do

• Long-lived malware can pass through. A release that remains undetected beyond the waiting period still needs scanning, testing, and review.
• Weak build permissions remain dangerous. A delay does not fix exposed credentials or a release workflow that runs untrusted code with privileged access.
• Unmanaged installs bypass policy. Developer machines, temporary scripts, and separate build systems need the same version and source controls.
• Delay has a cost. A needed compatibility fix or product capability may justify an exception. That decision should be explicit, tested, and reversible.

The opportunity is not perfect prevention. It is a release system that can distinguish routine change, urgent repair, and exceptional business need without improvising every time.

07Safe speed is a product capability

Dependency policy affects more than security. Predictable updates reduce surprise regressions, make incident response faster, and give enterprise buyers confidence that the product's building blocks are controlled. The same operating discipline improves release quality and delivery forecasting.

Ask one question in your next product review: if a popular dependency published a compromised version today, would your automation adopt it before your team could evaluate the signal? If the answer is yes, a short cooldown is a high-value place to start.