Speed helps patches ship fast, but it also lets malicious releases spread just as fast.
Speed is the decisive factor when a security patch needs to reach production quickly. However, when a compromised maintainer account pushes a malicious release, thousands of automated builds pick it up, speed can become your worst enemy.
On 3 June 2026, RubyGems shipped a feature in Bundler 4.0.13 called cooldown. The idea is simple and very effective: Bundler can now refuse to install a gem version until it has been public for a set number of days. A version that went up an hour ago will not be resolved until it has aged past the window, even if it is the newest version available. RubyGems describes this as a time-based filter that skips releases too new to have been scrutinised.
While the update may seem like a small quality-of-life change, in fact, it is a direct response to how maintainer account takeovers and malicious package releases now work.
The lesson applies well beyond Ruby: organisations need to decide how fresh unreviewed third-party code is allowed to be before it runs in a developer laptop, CI job, or cloud build pipeline.
Could a newly compromised package reach your production environment today?
Zazmic will assess your dependency and CI/CD pipeline, identify supply chain security gaps, and recommend practical next steps to strengthen your security posture. Schedule your assessment with us !
The Attack Pattern: Speed is the Exploit
If you look at the npm incidents of the past year, you will notice the same pattern.
In September 2025, the maintainer of chalk, debug, and other widely used packages was phished. Eighteen packages with a combined 2.6 billion weekly downloads shipped malicious versions that targeted cryptocurrency transactions. The malicious versions were live for roughly two hours before they were removed.
A week later, a self-replicating worm known as Shai-Hulud spread through the npm ecosystem. It affected more than 500 packages, harvested AWS, Google Cloud, and Azure credentials, established persistence through GitHub Actions backdoors, and used stolen maintainer tokens to keep propagating.
In March 2026, Axios, a JavaScript HTTP client with more than 100 million weekly downloads, was compromised through stolen npm credentials. Attackers published two poisoned versions that pulled in a phantom dependency and deployed a cross-platform remote access trojan on macOS, Windows, and Linux.
What these incidents share is timing. None of the malicious versions lasted long. They were spotted and removed in hours. The damage came from automated installs that happened during that short window: CI/CD pipelines, developer machines, and build jobs configured to pull the latest acceptable version without a release-age check.
Today, attackers do not need to persist in a registry for weeks to impact your systems. The only thing they need is to be available long enough for automation to trust them.
The Solution: How Bundler Cooldown Works
RubyGems.org now publishes a created_at timestamp for every gem version. During dependency resolution, Bundler skips anything younger than the configured window and selects the most recent version that has aged past it. The recommended place to set it is a single line in the Gemfile, committed with the code, so every developer and every CI environment enforces the same policy:
source "https://rubygems.org", cooldown: 7
Most smash-and-grab malicious releases rely on immediate adoption. A short release-age gate gives maintainers, registries, malware scanners, and the wider community time to detect and remove suspicious versions before they enter your build. As a result, you do not stop updates, but you hold the newest ones back until they have had time to be vetted.
What Cooldown Does Not Do
Cooldown is a delay, but it should not replace judgement. It does not inspect source code or prove that an aged package is safe. It also does nothing about a vulnerable version already pinned in your lockfile.
Additionally, keep in mind that the delay cuts both ways. The same delay that holds back a malicious release can also hold back a legitimate security fix. That is why the override exists. Bundler allows a --cooldown 0 escape hatch for cases where waiting is the wrong default, such as an actively exploited vulnerability or a confirmed advisory requiring an urgent upgrade.
The operational rule should be simple: wait on convenience updates, fast-track real vulnerabilities. Dependabot’s cooldown option applies to version updates, not security updates, while Renovate’s minimumReleaseAge is designed to delay routine dependency updates so researchers and automated tools have time to catch malicious behaviour.
That split is the difference between sensible friction and dangerous delay. If you adopt cooldown, pair it with vulnerability monitoring, software composition analysis, lockfile review, and tooling such as bundler-audit for Ruby projects. A release-age policy should never become the reason you miss a critical patch.
Delay as a Cross-Ecosystem Control
RubyGems is not the only solution available. pnpm documents minimumReleaseAge as a way to delay dependency updates because malware is usually detected quickly; in pnpm v11, the default is 1,440 minutes, or one day, with guidance showing how teams can extend that to one week.
Package managers are beginning to recognise time as a security boundary. Freshness used to be treated as a feature. In supply chain security, freshness can also be an exposure.
From a Google Cloud security perspective, cooldown belongs inside a wider software supply chain security model. It should sit alongside Artifact Registry for controlled package and image storage, vulnerability scanning through Artifact Analysis, SBOM generation, provenance, and deploy-time enforcement through Binary Authorization for GKE and Cloud Run.
The key point is to control the path from the public package to the running workload. A package should not move from registry to build to production without checks on age, source, integrity, vulnerability status, provenance, and deployment eligibility.
Next Steps to Secure Your Supply Chain
Start by mapping where dependencies enter your environment. That includes local developer machines, CI runners, container builds, serverless deployments, and internal templates. Then decide which registries are allowed, which package managers need release-age gates, and where exceptions are permitted.
For public packages, use a conservative default: around seven days for routine updates is a practical starting point. For internal registries you operate, the window may be shorter or zero. For urgent security advisories, allow an approved bypass and document who can use it.
Then connect the control to the rest of your cloud security posture:
Use lockfiles
Scan dependencies and containers
Generate SBOMs
Store artefacts in trusted repositories
Enforce signed and attested images before deployment
Keep secrets out of build environments wherever possible.
Monitor CI/CD for unusual install behaviour, unexpected package scripts, and new outbound network calls during builds.
With this setup, you go from a small package-manager setting to a serious DevSecOps control.
Do Not Be the One Who Finds the Malicious Release First
RubyGems' cooldown proves that the fastest dependency is not always the safest dependency. A few days of patience can protect your organisation from serious security risks.
Most malicious versions are caught within hours. A short cooldown is a way of making sure your build pipeline is not the first place they succeed.
Need a second set of eyes on your dependency pipeline? Zazmic helps you lock down the path from package to production. Book a call with us to review your software supply chain before the next compromised package reaches your build.