--- title: "Cooldown & Minimum Package Age Policies | Cloudsmith" description: "Cloudsmith cooldown policies enforce a minimum package age blocking newly published packages until they clear review." canonical_url: "https://cloudsmith.com/product/package-cooldown-policies" last_updated: "2026-08-11T12:53:47Z" --- # Cooldown & Minimum Package Age Policies | Cloudsmith 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. [Book a demo](/book-a-demo) [Read the documentation](https://docs.cloudsmith.com/supply-chain-security/policy-as-code/cooldown-policy) 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 attack | Using Cooldown Policies | | --- | --- | | In September 2025, the Shai-Hulud worm published malicious versions of over 700 npm packages, spreading by publishing new versions faster than teams could react. | Cooldown 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. | | Two 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. | Package 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. ### What is a cooldown policy? 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. ### Which package formats are supported? 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. ### Does it affect packages already cached in my workspace? 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. ### What happens if I update or disable the policy? Every package in the index is re-evaluated automatically. ### How do I create a cooldown policy? 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. ### Which plans include cooldown policies? 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. ### Can I exempt a specific package version from the cooldown period? 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. ### How do I see which packages a cooldown policy is blocking? 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. ### What's the difference between a cooldown policy and quarantine? 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. ### What happens if a package is missing publish date metadata? 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. ### Does a cooldown policy work with connected repositories? 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. ### [How Cloudsmith cooldown policies block newly published packages without disrupting your builds](/blog/how-cloudsmith-cooldown-policies-block-newly-published-packages-without-disrupting-your-builds) Cooldown policies at the index level mean your package manager resolves to compliant versions automatically. Cloudsmith implements this for npm and Python. ### [What is a package cooldown policy? How to prevent malicious dependencies from entering your environment.](/blog/your-upstream-is-not-your-friend-why-security-teams-are-demanding-package-cooldown-policies) Point-in-time scanning treats trust as a moment. Cooldown policies treat it as a discipline: new packages are held, continuously evaluated against evolving threat intelligence, and released only when they clear policy. ### [How to configure time for cooldown policies](/blog/how-to-configure-time-for-cooldown-policies) Understand how configuring time-based cooldown controls on the client-side can become a security headache ### [How to use Cloudsmith as a dependency firewall](/blog/how-to-use-cloudsmith-as-a-dependency-firewall) A practical guide to building a dependency firewall with Cloudsmith, from upstream configuration and cooldown policies to the GitOps exception workflow and decision log auditing. Talk to a Cloudsmith expert about rolling out cooldown policies across your development environments. [Book a demo](/book-a-demo)