Cooldown Policies
Block unproven dependencies from entering your builds with cooldown policies
Cooldown policies hold newly published packages until they clear a minimum age threshold, so unproven code can't slip into your builds and put your supply chain at risk.
The exposure window
Threat actors are using the software supply chain to exfiltrate data and cause reputational damage
Recent supply chain attacks follow the same pattern: newly-published packages containing malicious code are pulled into builds before anybody realizes they're bad. Here's how cooldown policies help mitigate these attacks.
supply chain attackIn September 2025, the Shai-Hulud worm published malicious versions of over 700 npm packages, spreading by publishing new versions faster than teams could react.
Using Cooldown PoliciesCooldown policies hide every new package version until it clears your minimum age threshold, so a worm's first hours of distribution never reach a build.
supply chain attackTwo backdoored axios releases carrying a remote access trojan stayed live for just three hours before detection, long enough for any pipeline resolving to "latest" to pull them.
Using Cooldown PoliciesPackage managers resolve straight to the newest version that has already cleared the cooldown window, so pipelines pulling "latest" never see a release still inside its risk period.
How cooldown policies help
Cooldown policies close the attack window and keep your teams safe
A cooldown policy holds every new package version back until it clears that window, then gets out of the way automatically. While the policy is in place your teams remain productive and builds continue without interruption.
Applied before packages ever land
Cooldown policies run at the Cloudsmith repository level, covering packages proxied straight from a public upstream as well as versions already cached in your workspace. Developers, CI/CD pipelines, and AI agents already pointed at that repository are automatically protected: no reconfiguring package managers project by project, and no client-side security tool to install.
Minimum age, enforced automatically
Set a cooldown period in days. Any package version published more recently than that is hidden from the index until it ages out.
Automatic reversal
Update, disable, or delete the policy and every package is re-evaluated immediately. No manual clean-up required.
Runs first, every time
Cooldown policies are always terminal and evaluated at the highest precedence, so a blocked package is stopped before any other policy needs to run.
PRODUCT DEMO
Close off this critical attack vector in moments, not months
In this simple product demonstration you'll learn how to create your first cooldown policy, blocking off newly-released packages that haven't passed your minimum age threshold.
developer experience
Developers remain productive and builds continue
Cooldown policies enforce silently in the background. Most developers won't notice a thing until a pinned or newly published version runs into the window.
No broken builds, no re-runs
Package managers resolve straight to the latest compliant version automatically. Non-compliant versions are skipped before resolution completes, so builds never break on a blocked package and nobody has to diagnose a failure and re-run the build.
Clear developer feedback and error messaging
Cloudsmith returns a 404 or 403, most common when a lockfile or pinned version points at a package still inside its cooldown window. Choosing a version that satisfies the cooldown resolves it. For npm and uv (Python), Cloudsmith returns the policy name, description, and ID directly in the 403 response, so developers can see why a package was blocked without pinging the platform team.
Immediate enforcement
Update your cooldown window at any time. Cloudsmith re-evaluates every package in the index automatically, no redeploys or cache purges needed.
Frequently Asked Questions
Here's what security and platform teams ask us most when they're evaluating cooldown policies, covering supported formats, what developers see when a package is blocked, and how the policy fits alongside your other controls.
A cooldown policy hides newly published package versions from your repository index until they reach a minimum age based on the version's publish date. This protects your supply chain from packages that haven't yet undergone sufficient community scrutiny.
Cooldown policies currently support Go, Maven, npm, NuGet, and Python packages that originate from a public upstream source. Additional format support is on our roadmap.
By default, yes. Cached packages that don't meet the age requirement are quarantined and hidden from the index until the cooldown period elapses. You can exclude already-cached packages from the policy scope if you only want to protect newly ingested versions.
Every package in the index is re-evaluated automatically.
Create one from the Policy as code tab in your Cloudsmith workspace using the Cooldown period template, or manage it programmatically through the Cloudsmith API or Terraform provider. Only one cooldown policy can exist per workspace.
Cooldown policies are available in early access for Ultra and Enterprise plans. Contact us to request access or register your interest in additional format support.
Not directly, during early access. You can exclude entire repositories, formats, or already-cached packages from a policy's scope, but per-version exemptions aren't yet supported. If a version urgently needs to bypass the policy, your security or platform team can download it and upload it to Cloudsmith directly, since manually uploaded packages carry no upstream publish metadata for the policy to evaluate.
Cached packages held back by a cooldown policy show a HIDDEN status in Cloudsmith and via the API. Search your workspace for status:hidden to find them, or hover over the status to see why a specific package was hidden. Rely on that search rather than the policy's match count: decision logs, and therefore match counts, are only generated for cached packages that get quarantined, so a cooldown policy can report 0 matches while it's actively hiding packages that were never cached.
A cooldown policy is proactive and time-based. It holds every newly published package during its highest-risk window, whether or not a threat has been identified yet. Quarantine is reactive, triggered only after a specific vulnerability or malware indicator matches a package. Most teams run both together.
The policy fails open. If an upstream hasn't populated the age metadata Cloudsmith checks, such as npm's time field or Python's upload-time field, the policy can't determine the package's age and won't hide it from the index. Factor this into your risk assessment when evaluating policy coverage.
Not yet. Connected repositories aren't currently supported by the cooldown policy feature. This is a known limitation during early access.
Helpful resources
Related resources
We've compiled these resources to help your organization adopt and apply cooldown policies effectively, closing off this major attack vector.
Ready to close off this critical security gap?
Talk to a Cloudsmith expert about rolling out cooldown policies across your development environments.