Why "Up-to-Date" Packages are No Longer "Safe"

The image is licenced by Magnific.

‍

If you’ve been following the open-source ecosystem over the past few years, you’ve probably noticed a pattern: a trusted package gets a new version, automate tooling pulls in the package almost immediately, and injects some code that was never supposed to be there. 

‍

We saw this play out with the xz/liblzma backdoor in early 2024 (Openwall). This was a multi-year social engineering campaign that embedded a backdoor into a core Linux compression library. We also saw this with polyfill.io, when the service changed hands and the new owner injected malicious scripts into a CDN used by hundreds of thousands of websites (Sansec). We’ve, most recently, repeatedly seen it in the npm and PyPi ecosystems, with malicious packages masquerading as popular libraries or slipping in as compromise updates to real packages. Axios being among the recent high-profile names that was dragged into the mess (GitHub).

‍

These incidents keep happening because the attack surface is real and well-understood by attackers. For a long time, one of the biggest accelerants was automatic dependency updates. 

‍

‍

The Automation Problem

‍

Automated dependency updates tools like Dependabot, Renovate, or other similar bots are genuinely useful for keeping your dependencies current. They also help surface security patches and reduce the scut work of scanning for stale packages. But they also create a tight feedback loop between a malicious published version and a malicious version that is merged into your codebase. 

‍

Here's what an attack like this can look like in practice: 

• An attacker compromises a maintainer’s npm account.
• A malicious version goes live on the registry.
• Then, typically within hours, automated bots open PRs across thousands of repositories.
• Developers, who are used to trusting these minor version bumps, merge the PRs without much thought.
• The malicious package runs during install or at runtime, allowing it to exfiltrate secrets, adding backdoors, or other nefarious actions. 
• The package is eventually detected and removed from the repository, but the damage has already been done.

‍

Until now automation has been on the wrong side of the detection and adoption race.

‍

‍

GitHub’s Answer is to Wait

‍

GitHub just shipped a cooldown configuration for Dependabot which allows you to define a minimum age for a package (GitHub). The minimum age is defined in number of days, this is the minimum time a package must exist on the registry before Dependabot will open a PR to adopt it. This window gives the community time to vet the release, security scanners to flag issues, and the registry time to pull anything suspicious before that PR is opened.

‍

Below is a sample configuration for your .github/dependabot.yml: 

‍

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "daily"
    cooldown:
      default: 7    	# Wait 7 days for any new version
      semver-patch: 3   # Shorter window for patch releases
      semver-major: 14  # Longer window for major bumps

‍

Cooldowns can be tuned per semver type, allowing tighter windows for releases you trust and longer ones for major versions that could introduce vulnerabilities. 

‍

‍

What this Solves and What it Doesn’t

‍

While this is a meaningful mitigation it doesn’t solve everything. Lets examine what this might look like if we had a 7-day cooldown for one of the previous incidents. 

‍

First lets review the timeline of events for the axios attack as illustrated below from trendmicro.

‍

March 30, 2026 05:57 UTC: plain-crypto-js@4.2.0 published by nrwise@proton.me — clean decoy to build registry history

March 30, 2026 23:59 UTC: plain-crypto-js@4.2.1 published — malicious payload with postinstall: "node setup.js"

March 31, 2026 00:05 UTC: Automated npm security scanners flag plain-crypto-js as malware (six-minute detection)

March 31, 2026 00:21 UTC: axios@1.14.1 published by compromised jasonsaayman account (email: ifstap@proton.me)

March 31, 2026 01:00 UTC: axios@0.30.4 published — 39 minutes later, poisoning the legacy 0.x branch

March 31, 2026 ~03:30 UTC: npm administration removes all compromised versions and revokes tokens

‍

A 7-day cooldown window would have substantially reduced the impact of both the axios and npm incidents. That window should have given researchers enough time to flag those vulnerabilities. But what it doesn’t solve is seen in sophisticated, long-game, attacks like the xz attack, where malicious code was baked in over months of legitimate looking commits. No cooldown period is going to prevent that. It also doesn't help if the threat comes through a package that never gets flagged or if the updates are being performed manually. 

‍

But defense in depth is the key though, one solution won’t fix everything. Cooldowns pair well with other practices like pinning your dependencies, verifying checksums, reviewing changelogs, and using tools like npm audit or Sigstore-based supply chain verification. 

‍

‍

The Bigger Picture

‍

The frequency of supply chain attacks is on the rise. The ecosystem built for rapid iteration is being actively exploited. GitHub’s cooldown feature is an acknowledgement that keeping everything up to date is no longer a best practice in this case. 

If you’re using Dependabot, adding a cooldown is a low friction and low effort change that helps improve your security posture against the rise in supply chain attacks. Update your dependabot.yml, pick a window that fits your team’s needs and risk tolerance, and let the first few days of a release not turn into a supply chain fire drill.

‍

‍

About the Author

‍

Jordan Darrah is a Security Consultant at Cloud Security Partners. Jordan's interest in IT started when she was working as a menswear fashion designer and bridal seamstress. Since then, she has built a diverse technical background spanning hardware repair, systems administration, regulatory compliance, and penetration testing.

‍

Currently, Jordan specializes in application and cloud security assessments, where she evaluates system vulnerabilities and conducts penetration tests. Jordan holds multiple industry certifications, including CISSP, eJPT, and CompTIA PenTest+. She also runs an OSCP study group and maintains a blog where she breaks down concepts and tools for new security professionals.

‍