GitHub and PyPI Add Time-Based Defenses Against Supply Chain Attacks

GitHub and PyPI have activated new time-based barriers to slow supply chain attacks. Dependabot now waits a default of 72 hours before opening pull requests for new package versions, and PyPI no longer allows new files to be added to a release older than 14 days.

The platforms introduced these changes in recent weeks with a shared goal: inserting time delays to reduce the typical damage from supply chain attacks. In Dependabot, the GitHub bot for managing dependencies, the update applies a 72-hour wait before creating a pull request when a new package version appears. On PyPI, the central Python package repository, the platform has rejected uploads of new files to releases published more than 14 days ago since July.

Dependabot cooldown details

The Dependabot adjustment does not affect urgent security patches. The wait applies only to version updates that are not considered security-related. Security updates remain immediate so critical fixes are not delayed when risk is already identified. The goal is to prevent projects from absorbing a freshly published version that has not yet undergone community review or that an attacker may have inserted after compromising an account or publication workflow.

Teams relying on automation will notice changes in their update cadence. The wait can be adjusted or disabled using the cooldown option in the dependabot.yml file, which is relevant for repositories with strict maintenance windows or their own validation processes. GitHub Enterprise Server will also receive the feature, with deployment planned for GHES 3.23.

PyPI 14-day release restriction

On PyPI, the 14-day restriction targets a tactic that has caused problems: poisoning of older stable versions. If an attacker obtains publication tokens or access to a poorly protected CI/CD pipeline, they can upload a new artifact to a past release with the same version number but different content. This complicates audits and breaks basic assumptions in many build environments.

The change was integrated on 8 July 2026 after the issue returned to prominence in March following compromises in projects such as LiteLLM and Telnyx linked to a mutable reference when using the Trivy GitHub Action. PyPI acknowledges that the ecosystem still lacks standardized semantics and APIs to declare whether a release is open or closed. The platform expects progress through initiatives such as the Upload 2.0 API and Staged Previews, which should enable safer workflows without relying solely on rigid rules.

For development teams, these measures require adjustments to habits. It is advisable to account for the 72-hour delay in automatic Dependabot pull requests, prioritize security updates, and set an explicit cooldown policy when project cadence demands it. Reinforcing lockfiles and dependency pinning also helps reduce unexpected changes in the package graph.

In the PyPI case, maintainers should plan to publish all wheels and artifacts within the 14 days following a release. If support for a new Python version is needed after that window, the recommended approach is to publish a new package version rather than modifying an old release. The real security belt remains elsewhere: minimum permissions on tokens, credential rotation, anti-fraud controls, and strict CI/CD hygiene to prevent a compromise from turning into endless cleanup.

No CVE is associated with these changes. They do not fix a specific vulnerability but rewrite the behavior of critical platforms so that a credential failure or malicious package has less room to maneuver and is harder to insert quickly.