AI coding agents: A call to action on dependency cooldowns

Spectra Assure Free Trial Get your 14-day free trial of Spectra Assure for Software Supply Chain Security Get Free TrialMore about Spectra Assure Free TrialRemember those words of advice for the over-eager from West Side Story? “Boy, boy, crazy boy, be cool boy.” They should be heeded by developers hell-bent on installing the latest updates to open-source software. Adopting a “cooldown” policy on updates can be a simple but effective way to avoid downloading malicious code. Noelle Murata, a senior security engineer at Xcape, said organizations should enforce a three-to-four-day minimum age requirement for new packages and updates. “A short delay gives the security community time to detect and remove malicious packages, reducing software supply chain risk.” —Noelle Murata A cooldown of at least one day — and ideally a week — keeps you from being first in line, said Waseem Ahmed, head of engineering at Secure.com. “By the time the version is eligible to install, the registry, the community, and scanners have usually had time to flag it and pull out.” —Waseem Ahmed Ahmed recommended treating anything freshly published as guilty until proven innocent. “The pattern over the last year is consistent: When a package gets compromised, the malicious version is usually caught and pulled within hours,” he said. “Axios was flagged in about three hours. The Red Hat packages hit by the Miasma worm were mostly revoked within hours, too.” Here’s why dependency cooldowns are essential in the AI coding age. [ See webinar: Develop Your New Playbook for AI-Driven Software Risk ] Kennedy Toomey, an application security researcher and advocate at Datadog Security Labs, made the case for dependency cooldowns in a company blog post. She noted that Axios had over 100 million weekly downloads and that 174,000 other npm packages depend on it. And compromised ecosystems can be particularly impactful. “Supply chain compromises have not been limited to JavaScript. Attackers have also targeted ecosystems like GitHub Actions and Python.” —Kennedy Toomey Datadog's 2026 State of DevSecOps report also raised the alarm about early updates. “Over the past year, we have seen the spread of several large-scale supply chain attacks, most notably s1ngularity and both Shai-Hulud attacks, due in part to organizations using malicious versions of libraries as soon as they’re released. To keep dependencies safe from malware, we recommend pinning dependency versions to a full-length commit SHA.” —DataDog researchers However, just because a GitHub Action is pinned to a commit SHA, or hash, doesn’t mean it’s safe, Varun Sharma, co-founder and CEO of StepSecurity, cautioned in a LinkedIn post. “The devil is in the details. Pinning to commit SHAs is a best practice, but you also need to make sure you’re not pinned to a compromised commit SHA.” —Varun Sharma Sharma noted that when Aqua Security’s Trivy ecosystem was compromised in March, there were multiple cases where actions were pinned to commit SHAs, but those SHAs pointed to compromised imposter commits. “We have also seen Renovate and Dependabot create [pull requests] to update to the compromised commit SHAs, and those PRs got merged. These workflows continue to exfiltrate secrets on every run, even though they followed the ‘pin to SHA’ best practice.” —Varun Sharma Pinning dependency versions to commit SHAs can be problematic in other ways, warned Vishal Agarwal, CTO of Averlo. “Pinning to immutable versions resists supply chain compromise but slows your response when a legitimate vulnerability is disclosed in that dependency,” he said. “‘Patch fast and pin tight’ are in structural conflict. The resolution isn’t a universal rule. It requires understanding which dependencies in your environment create real exploitable risk, what they can reach, and what the consequences of compromise actually are. That context is what determines whether you patch fast, stay pinned, or apply a cooldown.” —Vishal Agarwal If pinning dependency versions to a commit SHA isn’t possible, the Datadog report recommends using Yarn or npm, two JavaScript package managers that provide new configurations with a minimum release age to allow time for new versions to be used by others. In addition, GitHub’s Dependabot can add a cooldown time for the same reason. “This buffer method keeps packages up to date but gives a set time before installation to reduce the likelihood of malicious software. A cooldown of one week could prevent a majority of malicious dependencies from taking root,” the Datadog researchers wrote. “Dependency cooldowns are a sensible first step. In the Axios compromise, malicious versions were live for three hours. A 12-hour cooldown would have blocked most of the damage.” —Vishal Agarwal However, cooldowns are not sufficient alone, Agarwal added. “Attackers are already adapting. In the TanStack attack, malicious packages carried valid cryptographic provenance attestations, meaning even organizations verifying package legitimacy got a green light. Patient attackers will delay malicious execution or find other workarounds to survive any cooldown window.” “Transitive dependencies compound the problem. The average application now contains over 1,100 open-source components, and 64% of those are transitive dependencies pulled in automatically by your direct dependencies. You never chose them. Most were never reviewed. Cooldowns apply to what you explicitly install, not to the full dependency graph your application actually runs.” —Vishal Agarwal John Strand, owner of Black Hills Information Security, said transitive dependencies increase risk because many developers don’t fully understand everything that’s ultimately being included in their applications. “It’s very similar to the famous XKCD comic about modern infrastructure resting on a handful of critical open-source projects. The ecosystem is incredibly dynamic and powerful, but every additional dependency expands the potential attack surface.” —John Strand Strand argued that cooldowns sound good in theory but aren’t practical in the real world. “Modern software development moves too quickly, and organizations are already under pressure to deploy updates and security fixes rapidly. Delaying every new dependency would introduce significant friction into development and could actually create additional security problems,” he said. “The theory is that if you wait, someone else will discover the problem first. My concern is that this assumes malicious activity is obvious and immediate. The XZ Utilities incident showed us the opposite. That attacker spent years building trust before introducing malicious code. Nation-state actors are often willing to move slowly and patiently, so simply waiting isn’t a reliable defense.” —John Strand Strand said dependency cooldowns are flawed because waiting isn’t automatically safer. "The inverse risk is that a new package or dependency may contain an important security fix that needs to be deployed immediately. Simply waiting and hoping someone else discovers a problem first is not a sustainable security strategy,” he said.