A Cooldown Is Not a Sourcing Strategy

Blog

A Cooldown Is Not a Sourcing Strategy

Jonny Rivera

May 11, 2026

A Cooldown Is Not a Sourcing Strategy

A response to Datadog Security Labs’ “The case for dependency cooldowns in a post-axios world.”

The Datadog Security Labs piece on dependency cooldowns names a real problem and proposes a real mitigation. Cooldowns reduce blast radius. They would have blunted the Axios compromise. The configuration changes shipping in npm 11.10, pnpm, Yarn, and Dependabot are useful additions to the toolkit, and any team running production JavaScript should adopt them this quarter.

What I want to push back on is the framing underneath the recommendation, because it treats freshness as the primary risk variable in your software supply chain when freshness is a symptom, not the disease.

What does a cooldown do for you?

A cooldown is a time-based filter. It says: do not install a package version until N days have passed since publication. The bet is that the broader ecosystem will detect the bad version within that window, and your CI never pulls it.

That bet has held up reasonably well so far. Axios was caught in 3 hours. The s1ngularity packages were live for four. A 12-hour cooldown would have stopped both. A 7-day cooldown gives you enormous margin against the current attack pattern.

Notice what you are actually buying though. You are buying the assumption that someone else will find the malware first, that they will report it through channels your scanner subscribes to, and that the attacker did not build the payload to survive the wait. Datadog flags the third risk in the article itself: “patient attackers may delay malware execution to survive the waiting period.” Once cooldowns are widespread, that becomes the default attacker behavior. The window does not protect you. It shifts the timeline.

Where the framing breaks down

The most immediate gap is AI-assisted development. Datadog acknowledges “it is difficult to track which library versions a coding agent is using.” That is an understatement. Coding agents are now the dominant first-party producer of new dependency declarations in a lot of codebases, and they are not pulling from your governed source unless you have one and have constrained them to it. A cooldown configured in .npmrc does not bind an agent suggesting an npm install mid-session and a developer who runs it on a Friday afternoon to unblock a sprint.

When an agent scaffolds a new service and generates a package.json or requirements.txt as part of that output, those dependencies typically bypass whatever sourcing policy you have in place. The question is whether your sourcing policy has reach into how your team is actually adding dependencies today.

The second gap is transitive dependencies. Your direct dependencies might be on a 7-day cooldown. The packages those packages pull in are a different question. The cooldown is enforced by your installer against the resolver’s chosen versions, but the resolver is still walking a tree that you did not curate and largely cannot see. A package three layers deep with a wide semantic version range still ends up in your build. The cooldown applies to versions. It does not address the structural problem of an ungoverned tree.

Every CVE surfacing from a transitive dependency your team didn’t choose and can’t easily trace is a sprint interruption. Cooldowns delay when it arrives. They don’t fix the velocity problem it creates.

The third gap is semantic versioning itself. The article makes the point well: ^ and ~ ranges are an implicit trust statement about future code from an unauthenticated source. A cooldown narrows the trust window. It does not change the fact that you are accepting code from a maintainer account that you did not authenticate, on a publishing pipeline that you do not control, into a build process that you do.

The reframe: provenance, not patience

The conversation cooldowns are surfacing is the right one. The framing it has landed on is wrong. Cooldowns ask: when is this package safe to admit? The more accurate question is: where did this package come from?

A package pulled directly from npm carries the trust posture of npm. A maintainer account with a phished credential, a publishing pipeline with no enforced provenance, a registry whose primary optimization is publishing speed. A cooldown does not change any of that. It delays your exposure to it.

A package pulled from a governed source carries a different posture. Provenance has been verified before the version was admitted to the catalog. Build integrity has been checked. Policy has been applied at the source, not downstream of it. That posture survives whether the version is 1 hour old or 1 year old, which is what you actually want, because the freshness of a release is not what determines whether it should be in your build.

This is the distinction between software supply chain defense and governance that we think about at ActiveState. ‘Scan and Pray’ asks how fast you can detect a bad package after it enters your environment. ‘Curate and Govern’ asks what would have to be true for that package to never enter your environment in the first place. A cooldown is a useful refinement of the first model. It is not the second model.

What to do right now

Adopt cooldowns. They are cheap and they help. Set them at 7 days where you can, 12 hours at minimum on anything you cannot push further. Apply them in Dependabot for the configurability across ecosystems. Pin direct dependencies. Audit your wide ranges.

Then ask the harder question. Your direct dependency declarations are a small fraction of what is actually running in your builds. What governs the rest of the tree, who owns the policy that decides which versions are admissible, and what would it take to make that decision happen at the source rather than in your CI logs after the fact. Then look for solutions that help you govern open source at the source.

Cooldowns are defense in depth. They are not where software supply chain security comes from.

Frequently Asked Questions

What is a dependency cooldown and how does it work?

A dependency cooldown is a time-based filter applied by package managers (npm, pnpm, Yarn) or update tools like Dependabot. It prevents your CI/CD pipeline from automatically installing a newly published package version until a set number of days has passed — typically 7 days. The bet is that the broader security community will detect and report any malicious version within that window before your build pulls it in.

Do dependency cooldowns stop supply chain attacks?

Cooldowns reduce exposure to fast-moving attacks. High-profile incidents like the Axios compromise were detected within hours, so a 12-hour cooldown would have protected most teams. However, cooldowns rely on the assumption that attackers won't simply delay malware execution until after the waiting period expires. As cooldowns become standard practice, patient attackers are expected to adapt their tactics accordingly.

What is the difference between "Scan and Pray" and "Curate and Govern" in software supply chain security?

"Scan and Pray" is a reactive model: you install dependencies and scan for problems after the fact, hoping to detect bad packages quickly. "Curate and Govern" is a proactive model: dependencies are vetted and admitted to a governed catalog before they ever enter your environment, so policy is enforced at the source rather than downstream in CI logs. Cooldowns are a refinement of the first model; they are not a substitute for the second.

How do AI coding agents affect software supply chain security?

AI coding agents (like Copilot or other LLM-based tools) increasingly generate dependency declarations — package.json files, requirements.txt, and direct install commands — as part of scaffolding new code. These suggestions often bypass whatever cooldown or sourcing policy a team has configured, because the agent is operating outside the governed pipeline. This makes it critical to ensure your dependency governance policy has reach over how your team is actually adding packages today, not just how your CI resolves them.

Why are transitive dependencies a security risk that cooldowns don't address?

Transitive dependencies are the packages that your direct dependencies themselves depend on. Your package manager resolves and installs these automatically, often several layers deep. While cooldowns apply to the version your installer resolves, they don't give you visibility or control over the entire dependency tree you didn't curate. A package three levels deep with a wide semantic version range can still introduce a vulnerability — and because your team didn't choose it directly, it's harder to trace and remediate.

What should teams do right now to improve dependency security?

Start by adopting cooldowns — set them to 7 days where possible, 12 hours as a minimum. Apply them in Dependabot for cross-ecosystem coverage. Pin your direct dependencies and audit broad semantic version ranges like ^ and ~. Then go further: audit who governs your full dependency tree, where policy is applied (source vs. CI), and whether your AI-assisted development workflows are operating within your sourcing guardrails.

What is package provenance and why does it matter?

Package provenance refers to the verified origin and build integrity of a software package — knowing where it came from, who built it, and that it hasn't been tampered with in transit. Provenance-based governance means a package's admissibility to your build is determined by whether its origin meets your policy, not by how old it is. This posture holds regardless of freshness: a 1-hour-old package from a verified, governed source is safer than a 1-year-old package from an unauthenticated maintainer account on a public registry.

How do I configure dependency cooldowns in npm, pnpm, Yarn, and Dependabot?

npm 11.10 and later supports cooldown configuration via .npmrc. pnpm and Yarn have also shipped cooldown support. In Dependabot, cooldowns can be set per ecosystem in your dependabot.yml file, giving you cross-language coverage from a single configuration. Check the official documentation for each tool for the exact configuration keys, as these features are actively evolving.