Exempt specific packages from your cooldown policies
Exemptions defined in cooldown policies let specific packages skip the cooldown period and become available immediately, so a new release that fixes a vulnerability doesn’t have to wait. Exempt packages are still evaluated against your other active policies, and any action those policies define still applies.
Add exemptions in the cooldown policy’s Rego (the policy language used by Open Policy Agent) via the Cloudsmith web app, API, or Terraform provider. Each exemption applies to one format and matches by:
Package name prefix, for example @acme/
Package name, for example lodash
Package name and version, for example lodash4.17.21
Maven entries use the full groupId:artifactId coordinate.
Existing cooldown policies
Existing policies will continue to work. To add exemptions to one:
Created in the web app: we’ve already migrated these to the new Rego template. Edit the policy in the web app to add exemptions.
Created via the API or Terraform provider: we haven’t migrated these to the new template, because doing so would break on the next terraform apply for Terraform-managed policies. To add exemptions, either delete the policy and recreate it from the updated template, including the policy action that sets the package state to hidden, or contact us and we’ll help you migrate it. If you recreate it, do so straight away, because packages held in cooldown become available while no policy exists.
For more information, see Exemptions in the cooldown policy documentation.
Vulnerability records now show how likely each vulnerability is to be exploited, so you can order a backlog of High and Critical findings by what’s likely to be attacked, not just by severity…
Continuous risk detection replaces Trivy scanning, which is deprecated. Continuous risk detection checks every package against new vulnerability data as soon as it arrives, with no scheduled or manual rescans. It is powered by the Open Source Vulnerabilities database (OSV.dev) and has been generally available since August 2026…
Cloudsmith’s npm client support now serves npm's attestations and signing keys APIs, so provenance verification works through Cloudsmith just as it does when connecting directly to the upstream registry…
Two changes reduce the work involved in resolving npm packages: pnpm clients make fewer requests to Cloudsmith, and every npm repository makes fewer lookups to upstreams. No configuration changes are needed…
The Cloudsmith CLI now sends anonymous reports of unexpected errors to Cloudsmith by default, so we can find and fix crashes without waiting for a support ticket. It also connects through Transport Layer Security (TLS) intercepting proxies without turning off certificate verification, and installs credential helpers where package-manager upgrades can't remove them. Username and password login with 'cloudsmith' login and 'cloudsmith token' is deprecated and stops working on November 20, 2026…
Username and password login with cloudsmith login and cloudsmith token is deprecated and stops working on November 20, 2026. If you authenticate the CLI by running cloudsmith login or cloudsmith token with a username and password — including from scripts and CI jobs — you need to switch to an API key before that date…