Packages from Debian, Alpine, PyPI, and other ecosystems that use native version ranges are now matched against a broader set of OSV advisories, building on existing coverage for SemVer-based ranges.

Users with active vulnerability policies that use the 

 dataset may see more policy matches than before. This is expected: your policies are now being evaluated against a more complete set of advisories. It's broader coverage, not noise.

 for more information on how to access the OSV.dev dataset to create your vulnerability policies.

Cloudsmith's Terraform provider (v0.0.75) now supports full lifecycle management of policies and policy actions as code.

We’ve added native Terraform resources and data sources that let you create, configure, and manage policies as code, including Rego rules and associated actions, directly from your infrastructure-as-code workflows.

Four new Terraform constructs are available:

Defines a workspace-scoped policy with a Rego rule, precedence, enabled state, and whether it is terminal in the evaluation chain.

Attaches one or more actions to a policy (e.g. quarantine a package, add/remove tags, hide a package), each with its own precedence.

Returns a specific policy by its slug for use as a reference or output.

: Queries multiple policies by name pattern or sort order.

 in the terraform-provider-cloudsmith GitHub repository for an example of a Terraform module that uses the Cloudsmith provider to create:

Terraform Registry: Cloudsmith documentation

Policy as code is currently available in early access. If you would like to try this feature, please 

Manage policies as code with Terraform

Two additional policy evaluation triggers are now available, ensuring that policies are enforced consistently across repositories without manual intervention.

Policy evaluations will now also trigger when:

A policy or policy action is created, edited, or deleted.

 Any change to your policy configuration immediately re-evaluates affected packages against the updated ruleset, so your policy coverage stays current without manual intervention.

 Any package that has not been evaluated against policies within the last 12 hours is automatically picked up for evaluation. This scheduled sweep runs every 12 hours, closing the gap for packages that may have been missed by event-driven triggers or that rely on a time-based value to determine what action to take.

These additional triggers are being rolled out to all early access customers over the next few weeks. They apply to policy-as-code configurations and do not affect legacy policies. An increase in policy matches is expected during this period as packages that were previously unevaluated are assessed for the first time.

These additional triggers complement the existing set, which includes package upload, resync, copy, manual scan, recurring scan, and when Cloudsmith receives updated package data, such as Common Vulnerability Scoring System (CVSS) or Exploit Prediction Scoring System (EPSS) updates.

More events now trigger policy evaluations

 resource for the Cloudsmith Terraform provider, you can define connected repository configurations in code alongside the rest of your Cloudsmith infrastructure.

You can now declare connected repository configurations alongside your other Cloudsmith resources, apply them through standard 

 workflows, and track changes in version control.


For more information about managing connected repositories with the Cloudsmith Terraform provider, see 

Terraform Registry: Cloudsmith - Repository Connected Resource

Connected repositories are in early access and are currently supported for Maven, Docker, Python, NPM, Go, Cargo (Rust), NuGet, Helm, Conda, and Conan. Please 

 if you are interested in trying them.

For more information about connected repositories, see our 

Create and manage connected repositories with Terraform

 dist-tag to the package with the highest semantic version number, which may not match what the upstream registry considers 

, lets upstream distribution tags (dist-tags) override Cloudsmith’s semantic versioning (SemVer)-based tag assignment.

When enabled, Cloudsmith's npm metadata logic still uses SemVer as the baseline, then checks for the 

 dist-tag in the upstream registry. The upstream tag is applied as an override only if the corresponding version is present within the versions available to the client. If the version is not available (which can be affected by index policy controls, like cooldown policies), the 

 tag defaults to the semantically highest available version.

npm users who want to closely replicate npm upstreams. For example, engineering teams who:

Publish packages to both npmjs.com and Cloudsmith

Use release tooling that depends on dist-tags

Pull packages using tag-based resolution (e.g. @latest or @next) rather than pinned versions

You can configure upstream tag precedence for a repository by setting 

"npm_upstream_tags_take_precedence": true

Align npm dist-tags with upstream registries

A cooldown policy now filters non-compliant package versions from the repository index before package managers ever see them. This provides both security control and a better developer experience: clean resolution to the next compliant version, no build failures, and no waiting.

Malicious packages typically live in public registries for hours before detection. In that window, automated CI/CD pipelines can pull them straight into customer builds. A package cooldown policy closes that gap by enforcing a minimum age requirement on packages before they're available to install.

Previously, cooldowns were enforced at the point of download, meaning a build requesting a version still within the cooldown window would fail to resolve. Now, we’ve moved enforcement to the repository index, filtering out non-compliant versions before package managers see them. Builds resolve cleanly to the first available compliant version, with no iterative build failures.

Non-compliant package versions are filtered automatically:

 Package managers only ever see versions that meet your policy requirements.

 Builds succeed without retries, failures, or workarounds. Developers don't need to worry about the impact of having a cooldown policy in effect.

Enforcement is server side and enterprise wide:

 Security teams configure policies once in Cloudsmith, applied consistently across every consumer of the registry, no per-client configuration required.

 (for example, 3 days) for the repositories and formats you want to protect.

When a package manager requests the index, Cloudsmith evaluates every version against the policy in real time.

 are filtered from the index, and the package manager 

automatically resolves to the first available compliant version

This feature is available in Early Access for Ultra and Enterprise customers.

 to request early access or register interest in additional format support.

Cooldown policies now prevent builds from seeing non-compliant packages

Cloudsmith CLI Action v1 is now deprecated. Security-only patches will continue until 31st December 2026, after which v1 reaches end-of-life (EOL).

Migrate to v2 before 31st December 2026 to avoid disruption.

v1 runs on Node.js 20, which reached EOL on 30th April 2026. Continuing to ship a GitHub Action on an unsupported Node.js runtime exposes pipelines to unpatched runtime CVEs, and to GitHub Actions failures due to the 

deprecation of Node 20 on GitHub Actions runners

v2 runs on Node.js 24. For more information about Node.js releases, see the 

 v1 (or pinned at v1.x.x) in their GitHub Actions workflows. For example:

Customers automating Cloudsmith pushes/pulls in CI/CD

Customers using OIDC to authenticate GitHub Actions against Cloudsmith

Breaking changes and important information

No input or output names have changed in v2. Before migrating to v2, review the following breaking changes:

GitHub-hosted runners are unaffected. Self-hosted runners must explicitly provide Node.js 24+.


 input has been updated to provide organization-specific audience claims. 

If your existing OIDC trust configuration relies on the legacy 

 claim, you must either update your validation logic within Cloudsmith or explicitly set 

oidc-audience: 'api://AzureADTokenExchange'

 in your workflow YAML to maintain current behavior.

To migrate to v2, make the following one-line change in your affected GitHub Action workflows:

If you have any questions or concerns about this change, please 

Vulnerability detection now covers ecosystem-native OSV advisories

Other logs

Manage policies as code with Terraform

More events now trigger policy evaluations

Create and manage connected repositories with Terraform

Align npm dist-tags with upstream registries

Cooldown policies now prevent builds from seeing non-compliant packages

Deprecating Cloudsmith CLI action v1