GitHub and PyPI Introduce New Rules to Counter Open Source Supply Chain Attacks

To curb the rapid spread of malicious open-source packages, ecosystem maintainers are overhauling the default behaviors of automated dependency tools and package registries. GitHub and the Python Package Index (PyPI) have introduced structural policy changes specifically aimed at neutralizing fast-moving supply chain attacks and retroactive dependency poisoning. Central to these updates is a new GitHub Dependabot cooldown mechanism that introduces a deliberate delay before automated pull requests land in developer repositories, alongside strict new upload limits on older PyPI releases.

Delaying Automated Updates to Defeat Fast-Spreading Attacks

Automation in modern software engineering has created a double-edged sword: while automated pull requests make patch management effortless, they also provide an express lane for malicious code. When threat actors compromise a legitimate package or publish a malicious version, automated dependency update tools frequently fetch the bad release within minutes. If developers merge these updates automatically or test them in unisolated CI environments, the attacker achieves immediate execution inside target networks.

GitHub’s response addresses this window of exposure directly by introducing a three-day delay for Dependabot pull requests. By default, Dependabot will now wait at least 72 hours after a package version is published before opening a pull request for a non-security version bump. This three-day buffer aligns with operational reality: most malicious open-source packages are identified by automated scanners, community maintainers, or security researchers within 24 to 72 hours of initial release. Holding back automated pull requests during this initial window prevents poisoned releases from reaching downstream development pipelines before researchers can report them and registry maintainers can yank them.

The cooldown applies exclusively to non-security updates, ensuring that critical security fixes are not delayed. Project maintainers who require different timelines can customize or disable the feature by modifying their repository’s dependabot.yml configuration file.

PyPI Restricts Late Uploads to Shield Stable Releases

While GitHub targets the intake of new dependency updates, PyPI is closing off vectors that target older, long-established releases. Threat actors who obtain compromised API tokens or hijack maintainer publishing workflows often attempt to poison trusted historical releases rather than creating brand-new, highly visible major versions. For instance, an attacker might attempt to upload a pre-compiled, malicious wheel file tailored for a newer Python runtime directly to a years-old, highly trusted release tag. Downstream projects that rely on pinned version numbers or legacy distributions could then pull down the malicious asset without realizing the underlying release assets were modified.

PyPI’s new policy directly blocks the upload of new files to any release older than 14 days. Enforced alongside the standardization of the Upload 2.0 API and Staged Previews defined in PEP 694, this rule prevents attackers from stealthily modifying established releases even if they possess valid publishing credentials.

Registry data indicates the operational impact on legitimate developers will be minimal. During preliminary testing across the top 15,000 packages on PyPI, only 56 packages had published a late asset—such as a Python 3.14-compatible wheel—more than 14 days after the initial release date. Beyond preventing stealth compromises, this restriction simplifies incident response: by enforcing a hard 14-day cutoff on release modifications, security teams and registry maintainers can easily distinguish between untainted historical assets and potentially malicious additions.

The Threat Mechanics Behind Dependency Poisoning

Open-source software supply chain attacks rely heavily on speed and trust exploitation. Modern threat actors leverage stolen API tokens, credential stuffing, typosquatting, and social engineering to gain publish access to popular repositories across PyPI, npm, and RubyGems.

Once access is obtained, the attacker pushes a minor patch or release artifact containing a lightweight staging payload. This payload typically executes during the installation phase—such as inside a Python build script—to extract environment variables, steal cloud platform credentials, harvest SSH keys, or drop persistent backdoors into internal build systems.

Because downstream projects frequently configure floating version specifiers or employ automated dependency bots, a single malicious release can ripple through thousands of enterprise software builds within hours. By introducing structural speed bumps—such as Dependabot’s three-day hold and PyPI’s 14-day modification cap—the ecosystem forces a delay between publication and consumption, severely undermining the rapid-propagation tactics that modern supply chain attackers depend on.

Hardening Enterprise Build Pipelines

Organization security teams should leverage these ecosystem updates to audit and refine their own software supply chain configurations:

• Maintain Default Dependabot Settings: Keep the three-day Dependabot cooldown active for all standard dependency updates in repository dependabot.yml configurations, while ensuring security updates remain configured for immediate delivery.
• Transition to Short-Lived Credentials: Require project maintainers to migrate from static PyPI API tokens to Trusted Publishers using OpenID Connect (OIDC) authentication, minimizing the risk of persistent token theft.
• Enforce Strict Dependency Pinning: Mandate lockfiles and hash-based dependency resolution in CI/CD pipelines to ensure builds only consume explicitly verified package artifacts rather than unpinned releases.