What Happened
On December 17, 2024, PyPI implemented a rule blocking new file uploads to package releases older than 14 days. GitHub followed with a default three-day cooldown period in Dependabot before it automatically merges dependency updates. Neither platform has documented a real-world attack using the specific vector these defenses address.
This isn't a post-mortem. It's a pre-mortem.
Timeline
PyPI's 14-Day Rule:
- Implementation date: December 17, 2024
- Trigger: Preventative measure, not incident response
- Attack vector addressed: Release poisoning (adding malicious files to old, trusted releases)
- Known exploits using this method: None documented
GitHub's Dependabot Cooldown:
- Default setting: Three-day wait period before auto-merging
- Configuration: Adjustable per repository
- Rationale: Time window for community detection of malicious packages
- Documented bypasses: None yet
Which Controls Failed or Were Missing
No controls failed because no attack occurred. Both platforms implemented defenses against theoretical attack paths that security researchers identified but attackers haven't exploited at scale.
However, the implicit failures these defenses address are real:
Temporal trust assumptions. Your dependency management probably assumes that a package release, once published, remains immutable. PyPI's old architecture allowed maintainers to add files to existing releases indefinitely. If an attacker compromised a maintainer account, they could inject malicious code into a year-old release that your lockfile already pins as safe.
Speed-over-verification workflows. Dependabot's instant auto-merge feature optimized for speed, not validation. If a popular package published a malicious update, every repository with auto-merge enabled would pull it within minutes, before security researchers could flag it.
Missing: Time-based anomaly detection. Neither NIST 800-53 Rev 5 (SI-4, Continuous Monitoring) nor ISO 27001 (Annex A.8.16, Monitoring Activities) explicitly requires time-windowed analysis of supply chain updates. They mandate monitoring, but don't prescribe temporal heuristics.
What the Relevant Standards Require
NIST 800-53 Rev 5, SA-12 (Supply Chain Protection): Control enhancement SA-12(9) requires organizations to "employ [Assignment: organization-defined security safeguards] to detect tampering with supply chain elements." Time-based defenses qualify as a safeguard, but the standard doesn't mandate them specifically.
PCI DSS v4.0.1, Requirement 6.3.2: "Security vulnerabilities are identified and addressed" applies to dependencies. The three-day cooldown gives you a window to identify newly-discovered vulnerabilities before they auto-deploy. Without it, you're racing against automated merge timers.
SOC 2 Type II, CC7.2 (System Monitoring): Your auditor will ask how you detect unauthorized changes to system components. If you're auto-merging dependencies without a verification window, you don't have a satisfactory answer. The cooldown period creates an audit trail: "We wait X days and monitor security feeds before accepting updates."
ISO/IEC 27001:2022, Annex A.8.30 (Outsourced Development): This control addresses risks from external code. Your Statement of Applicability should document how you validate third-party updates. "We use Dependabot with default settings" isn't sufficient. "We enforce a three-day cooldown and subscribe to security advisories" is.
Lessons and Action Items for Your Team
1. Configure Dependabot's cooldown period based on your risk profile.
Don't accept the three-day default blindly. If you're in healthcare or finance, consider five to seven days. If you're shipping a low-risk internal tool, maybe one day is enough. The setting exists in .github/dependabot.yml:
updates:
- package-ecosystem: "pip"
schedule:
interval: "daily"
open-pull-requests-limit: 10
# Add this:
merge-delay: 5d
2. Audit your current PyPI dependencies for release age.
Run this check: Do you pin dependencies to releases older than 14 days? Good. If you're pulling from releases published in the last two weeks, you're in the danger zone where PyPI's new rule doesn't protect you. Consider adding a policy: "No production deployments of dependencies released in the last 14 days unless manually reviewed."
3. Map time-based defenses to your compliance documentation.
Update your System Security Plan (NIST 800-53) or Statement of Applicability (ISO 27001) to explicitly document temporal controls:
- "We enforce a minimum 72-hour delay before auto-merging dependency updates (SA-12)."
- "We reject dependencies from PyPI releases modified within 14 days of publication (SI-4)."
Your auditor will ask how you implemented these controls. Have the configuration files ready.
4. Build monitoring for the cooldown window.
Three days isn't useful if you're not watching during those three days. Set up alerts:
- Subscribe to GitHub Security Advisories for your language ecosystem
- Monitor
deps.devor Snyk for newly-reported vulnerabilities - Join language-specific security mailing lists (PyPA Announce for Python, npm security for JavaScript)
If a malicious package gets flagged during your cooldown, you catch it. If you're not monitoring, the cooldown just delays the inevitable.
5. Test your rollback procedures.
Time-based defenses buy you a window. They don't prevent compromise if you're not prepared to act. Run a tabletop exercise: "Dependabot opened a PR three days ago for package X. Today, a security researcher reports it's malicious. What do you do?"
Your answer should include:
- Close the PR (obvious)
- Check if any other repos auto-merged it already
- Verify your lockfiles to confirm the malicious version isn't deployed
- Document the incident for your next SOC 2 audit
If you can't execute that sequence in under an hour, your cooldown period isn't protecting you.
6. Don't rely on time alone.
PyPI's 14-day rule and Dependabot's cooldown are necessary, not sufficient. Pair them with:
- SCA tools that check dependencies against known-bad lists
- Signature verification for packages (where supported)
- Network egress monitoring to detect unexpected outbound connections from build systems
Time-based defenses are a speed bump. They work best when combined with other controls that can actually stop the attack.
The interesting thing about these defenses is that they exist before the attacks do. That's rare in security. Usually, we're patching after the breach. PyPI and GitHub looked at the attack surface and said, "This could happen, so we're closing it now."
Your job is to make sure your team benefits from that foresight. Configure the settings, document the controls, and monitor the windows. Otherwise, you're just waiting three days to get compromised instead of getting compromised immediately.
