By submitting this form, you agree to our 

Answer twenty questions about your artifact and supply chain practices. Get a custom report card showing your maturity score against key regulatory and compliance frameworks.

Artifact Security Maturity Assessment

Attackers only need one weak point in your supply chain to disrupt your builds, so security teams have to take precautions against every threat and advisory that comes out. Most teams no longer ask whether a software supply chain attack will affect them. They ask whether the right controls are already in place when it does.

Artifact management is the one layer every package passes through

Proactive defensive measures give teams the best opportunity to neutralize supply chain attacks before they strike, or to catch them early, before they can do significant damage. The artifact registry is the ideal location to enforce security policy because it provides a control point at ingestion for incoming packages. Because every stage of the development process pulls packages from the same artifact registry, policy decisions made at ingestion apply to developer workstations, CI builds, and production deployments.

A package cleared at ingestion enters downstream stages already vetted against your policies. A package blocked at ingestion never enters the build environment in the first place.

The attack model evolved but security controls didn’t

Attacks are more sophisticated now, targeting points earlier in the development process. Traditional malware, like ransomware, targeted individual machines and impacted them in an obvious way. Endpoint tools that scan files before execution evolved to combat this attack vector, and much of today’s security stack assumes this attack model as the default.

Supply chain attackers don’t need to target a specific machine. They compromise the actual software supply chain and what bad actors are trying to achieve through these attacks is much less transparent. Oftentimes malware exfiltrates sensitive information so that attackers can compromise additional systems. For example, Shai-Hulud spread by stealing npm, GitHub, and cloud tokens. Other times, the goal is to utilize the resources of a compromised machine for activities like cryptomining. These attacks are subtle by design and can delete evidence of their existence before you realize you’ve been compromised (like the Shai-Hulud variant that hit 

Attackers increasingly gain entry through the open source packages you depend on, and most teams rely on open source software to build the bulk of their applications. When an application uses hundreds or thousands of dependencies, attackers only need to compromise one to gain access.

When installing a package means running it

Beginning in September 2025, Shai-Hulud turned install-time malware into a self-propagating worm. TeamPCP, the group behind the Shai-Hulud attacks, open-sourced the code for the worm in May 2026, which 

gave rise to the Miasma and Hades versions

 and spread this attack type to PyPI, RubyGems, and other open source ecosystems.

These worm attacks rely on code that runs automatically at install time (e.g., npm preinstall / postinstall hooks, and equivalent build hooks in other affected ecosystems), so the malicious payload runs the moment a developer or CI runner installs the package.

Note: npm 12, released in July 2026, turns off install scripts by default. However, this feature only works with upgraded and configured versions of npm, and allowlists can re-enable install scripts. It’s also an ecosystem-specific solution, where a registry-level policy applies to every package that gets pulled in.

At that point, downstream scans of the build output or container image aren’t able to see the compromised package. Further, for newly released packages an advisory may not exist yet for the scanner to evaluate against. The critical point here is that this attack model exposes architectural gaps in security posture, not tooling failures. Scanners remain a critical and useful tool; however, they’re not designed to evaluate install-time code execution. As a result, controlling package ingestion is critical for defending against this type of attack. When installing a package means running its code, choosing a version means granting that code execution rights, so package selection becomes a trust decision.

Beyond malware: vulnerability and license risk

The Shai-Hulud class of attacks garners headlines, but software supply chain challenges exist beyond malware. Different organizations have different tolerances for package vulnerability risk signals, like CVSS severity, EPSS exploit probability, or a listing in CISA’s KEV catalog. Similarly, package licensing can have a significant impact on the legality and economic viability of using certain packages. The last thing teams want to happen is to get to the deploy stage only to find a critical vulnerability, or a license issue. Vetting package properties at the registry prevents issues from impacting downstream workflows.

AI agents multiply the dependencies that no one reviews

AI exacerbates the dependency problem. AI agents work at machine speed and can do so around the clock. These tools generate high volumes of code with more dependencies than humans have the capacity to review. Many of these are transitive dependencies and developers may not have visibility into these package decisions, especially with the increased volume of overall dependencies. This is another facet of package trust that can be dealt with by using the artifact registry as a control point for evaluating these packages at ingestion.

Activating the artifact registry as software supply chain control point

If the artifact registry is the ideal control point for the software supply chain, what does that control actually look like?

 allows you to enforce security policy before problematic packages reach your build environment. Policy enforcement is automatic and can be set once at the Cloudsmith workspace level and applied to every pipeline and developer that pulls from it. You can scope policy at the repo level as well, so any repos that require additional protection or leeway can be set up according to your needs.

The general shape of a dependency firewall includes:

: This one is straightforward. Packages with a known 

: This is a configurable, forced hold on newly released packages. Teams typically opt for 3–7 days, as most malicious packages are identified within days (or hours) of publication. A cooldown policy provides protection during the exposure window between when a package is published and when a threat advisory typically emerges.

: Writing policies around CVSS, EPSS, and KEV data. Every company has different thresholds for what they are willing to use, and that may change across environments (e.g., dev, test, prod). Cloudsmith’s policy management lets you write policy-as-code so you can have granular control over what gets in and what gets blocked.

: Write policies that check license type to protect your software from future licensing issues by limiting the types of licenses your developers can consume from the outset. For example, if you want to block copyleft AGPL licenses in distributed software.

The artifact registry touches the entire software development lifecycle. Traditionally, it was a tool for storing artifacts and packages, but its ability to enforce policy at ingestion makes it the ideal control point for software development. Preventing compromised packages from entering your environment denies attackers the opportunity to inflict damage on your systems. Clearing packages at the registry layer also ensures that downstream workflows and processes, like scanning, have safer inputs.

Every control described above is a policy you can write once and enforce across every repo. Learn more about 

Jason Myers

Technical Content Marketer

Why enforce supply chain security at the artifact registry 

 was compromised. This package has 18k downloads/week and the attack shares a lot in common with the 

August compromise of the "cacheable" and "keyv" packages

. If anything in your organization installed Tensorlake SDK 

 on or after October 8, 2026, treat the npm, GitHub, and cloud credentials on that machine as compromised, along with any AI coding tool configs. The malicious version ran a credential-stealing worm on install. Here’s how to check whether you’re affected, what to rotate, and how Cloudsmith helps keep versions like this out of your builds.

On October 8, an attacker published version 

 of the Tensorlake SDK, a package with about 18,000 weekly downloads. It contained two files that work together:

 runs through a preinstall hook and launches the payload using Bun.

a "math" file, holds the credential stealer and the worm that spreads it to other packages.

The worm exfiltrates npm and GitHub tokens, cloud credentials, and AI coding tool configuration files. It also establishes persistence, so attackers keep access after you remove the package. One infected install can give an attacker the keys to your pipelines and your AI agents at the same time.

 pointed out that this attack closely resembles the August compromise of the cacheable and keyv packages. Both are npm worms built on the mini Shai-Hulud code TeamPCP open-sourced this spring, and both use the same two-file pattern. There’s no evidence yet that the same group is behind both. The Hacker News reports that the attack shows attackers are now going after the AI tools developers rely on.

Two questions determine your exposure: did you install 

Compare the packages and versions in your lockfiles (

Match on whole package names, not substrings.

 When scripting your own checks, anchor on exact package names. Loose substring matching produces false positives (for example, flagging an unrelated package that merely contains an affected name as a fragment) and wastes triage time.

Check whether preinstall scripts can execute.

 Determine your npm client version and whether lifecycle scripts are enabled in your environments. If you are on npm 12+ with scripts disabled by default, an affected version that was pulled but never executed represents materially lower risk.

 could have run on a developer machine or CI runners, remove it. Then rotate npm tokens, cloud credentials and any secrets reachable from that environment, and review recent publish activity on your own packages.

Check Cloudsmith client and package logs.

 Review your Cloudsmith client logs and the package’s download logs to see whether 

 was requested or pulled. Client logs show which environments attempted to resolve the package. Package logs show whether the version entered your repository cache and which identities or pipelines downloaded it.

 Without a cooldown or malware policy, a developer or pipeline may have pulled 

 into your Cloudsmith cache. Search for it and quarantine any copies.

Old, dormant projects with pinned references are usually low risk, because a locked dependency tree keeps the version it already has. The exposure comes from a fresh install or a lockfile refresh that resolved to 

How Cloudsmith keeps newly published malicious packages out of your builds

Public registries supply most of your dependencies, and they serve the ecosystem well, but pulling from them straight into builds also means a malicious version can reach you minutes after it’s published. Cloudsmith sits between the public registry and your developers and pipelines as one policy-enforced control point. Two popular policies at Cloudsmith are cooldown policies and malicious package policies, which work hand in hand. Cooldowns handle the versions nobody has vetted yet. Malicious package policies take over once a version is known to be malicious.

Many package managers have client-side cooldowns built in, but they can be difficult to manage at scale for enterprises. Cloudsmith enforces the cooldown at the registry, whatever the client version or script settings, by holding back newly published upstream versions for a defined window before they become installable. Attacks like this one depend on speed: a malicious version is published, pulled into builds within minutes or hours, then withdrawn. A cooldown policy keeps those versions away from your teams during the window when they are most dangerous, giving the ecosystem time to flag them.

When the community does flag a version, malicious package policies act on it. Packages flowing through Cloudsmith are scanned for malware and matched against our database of malware advisories. With 

 from Cloudsmith, you can block versions flagged as malicious or matching known indicators. Once a package is identified as compromised, the policy stops it from reaching any consumer behind Cloudsmith, including after the cooldown window ends, and no developer has to update a manual blocklist.

When installs resolve through Cloudsmith, you get one place to enforce controls and one audit trail of what entered your environment. “Were we exposed?” becomes a search of your own records, rather than reconstructing it across every machine and pipeline. Policies only cover traffic that routes through them, so the practical first step is making sure your installs go through Cloudsmith instead of going straight to public registries.

With these controls in place, you can answer the next npm worm with one search of your Cloudsmith records.

Meghan McGowan

Product Marketing Manager

Tensorlake SDK npm package compromised

Using long-lived credentials in CI/CD and embedding static API keys in pipeline secrets are security risks. The CI platform authenticates a build job’s identity and context, and using short-lived tokens that expire on their own reduces exposure from a credential leak.

Previous discussions of OIDC covered using it to 

, and to authenticate workloads using your 

For any developer, the common denominator with using these tools is your individual workstation, which likely contains long-lived credentials.

At least one of these files on your local workstation likely contains long-lived API keys:

Each tool has its own login command and config file, which contains a copy of the API key in plain text. It’s the owner’s job to manually rotate these keys.

 npm worm targeted files that contained tokens on developer machines, like 

, and used them to access maintainer accounts and workflows.

You can sign into the Cloudsmith CLI with SAML via your company's identity provider. This creates a short-lived token that expires and rotates frequently. Credential helpers enable package managers like Docker and pnpm to borrow this authentication context from the Cloudsmith CLI, avoiding long-lived API keys being stored on disk.

The result is a short-lived access token, issued from your SAML sign-in. The CLI stores the token in your system keyring, and it expires on its own. The CLI renews it with a refresh token, so you are not sent back to the browser each time it expires. If you run 

 again while your session can still be renewed, the CLI simply renews it.

You now have a short-lived, SAML-backed session. The next step is to share that session with your package managers.

Step 2: Set up Cloudsmith credential helpers

Most package managers already know how to ask an external program for a credential. Docker has 

. Each one is a small, standard hook for a single question: 

"Who can give me a credential for this host?"

The Cloudsmith CLI now answers that question for all of them.

A credential helper does not log you in. It hands your active session to your package manager(s).

When a package manager needs a credential, it calls the helper. The helper asks the CLI for the current access token, and the CLI renews that token if it is close to expiry. Nothing is written into the package manager’s config file.

, not the project file, so the helper config never ends up in source control. If you already have an 

 for the same registry, the installer leaves it alone.

The provider answers only for Cloudsmith registries, doesn’t require 

. For crates.io and anything else, the credential helper steps aside and lets Cargo try the next provider.

Terraform does not tell a credential helper which repository it wants, so the installer writes your Workspace and repository into 

 for you. Terraform allows only one credential helper. If you already have one, the installer tells you and does not overwrite it.

 gives pip and uv a keyring backend that gets its credential from the Cloudsmith CLI:

 in that URL is not a secret. It is the literal username that Cloudsmith expects for token authentication. Your 

 names the repository, but it contains no credential at all.

 prints the current credential as JSON, ready for a wrapper script:

We are working on helpers for more package managers. The goal is to make the API key 

Open an issue on the Cloudsmith CLI GitHub repository

 and let us know which tool you use. Your requests help us decide which helper to build next.

Then use your tools exactly as you do today. One SSO sign-in. One short-lived session. Zero keys in your dotfiles.

OIDC took long-lived credentials out of your pipelines. Credential helpers take them off your laptop. Together, they move every part of your workflow toward short-lived, identity-based access.

Ian Duffy

Site Reliability Engineer

OIDC removed long-lived credentials from your pipelines. What about your laptop?

Cloudsmith now supports hosting public and private Nix binary caches. Teams that use Nix and NixOS can point existing 

 workflows at Cloudsmith without any additional tooling.

(Note: Nix format support is currently in Early Access.)

Nix builds work differently from most package ecosystems. Initiating a build in Nix begins with an evaluation of all the inputs that go into the build. This includes source code, dependencies, and build instructions, and each item gets hashed. The evaluation output is a derivation (a 

 file), which is a build recipe that describes what’s in the build. Nix then hashes the derivation to compute the package’s store path. Because downloading a pre-built version is faster than building from source, Nix then asks its substituters (remote binary caches like the default 

) whether that store path already exists. If it does and is signed by a key that Nix trusts, then Nix will download it. If it doesn’t exist, Nix builds it from scratch.

 packages from the public cache, but their own builds require a private binary cache, which is typically self-hosted. Relying on the public cache means accepting availability and bandwidth limits, which may not meet the needs of compliance-focused teams. Self-hosting a private cache with 

 or S3 means patching, scaling, and on-call duty for infrastructure that only serves packages.

 for Nix release channels. You must configure a separate upstream for each channel you want to use.

The first time you request a store path that Cloudsmith doesn’t have, it fetches the package from the configured NixOS channel, caches it, and serves it. Subsequent pulls are served from Cloudsmith’s cache, so builds are fast and keep working during a 

You can also push new Nix builds to a Cloudsmith repo, which then functions as a private Nix binary cache, but without the overhead tax of self-hosting.

Signing and verifying Nix packages in Cloudsmith

Where other ecosystems use package name and version number to identify packages, Nix uses a cryptographic hash to identify and verify them. Cloudsmith signs each package’s 

 with the repository’s ED25519 key on every read, and Nix verifies that signature against trusted keys. Because signing happens on every read rather than once at upload, key rotation takes effect immediately, with no backlog of packages to re-sign, and multiple keys can be active and signing simultaneously.

To get started using Nix with Cloudsmith, you can create a dedicated Nix repository. Add that repo to your Nix 

 list, and the repository’s public key to 

. This configuration means Nix treats Cloudsmith like cache.nixos.org. To proxy a public channel, add that as an upstream to the repo.

For private repos, authenticate with an entitlement token in a 

 file. Push Nix packages you build locally to your Cloudsmith Nix repo using 

 flag because locally built packages are unsigned and Cloudsmith handles signing on read.

For detailed setup instructions, see our 

Cloudsmith allows you to consolidate cached Nix packages in a single, cloud-native environment with multi-format repositories. Teams no longer rely on public cache availability, or pay the operational tax of self-hosting. Upstreams cache public channel packages in Cloudsmith for fast, reliable pulls.

Nix packages often sit outside the access controls and audit logging that cover the rest of your software supply chain. Bringing Nix into a Cloudsmith workspace, with 30+ formats in multi-format repositories, lets you govern Nix packages with the same access controls, entitlement tokens, and audit logs that you use on the rest of your software supply chain.

 for more information about using Nix in Cloudsmith.

Cloudsmith expands support to Nix

In Q3 we further improved platform security capabilities and enhanced developer experience.

 this quarter. This roundup provides a brief overview of each.

Policy management and risk detection are key security features in Cloudsmith and they reached general availability this quarter.

This is Cloudsmith’s policy engine that allows users to write policy-as-code across the web app, API, and Terraform provider.

With policy management you can write custom policies in Rego that are automatically enforced across your Cloudsmith account. This includes cooldown policies that hold newly released packages for a set period (see more on these below), policy templates to get started quickly, and decision logs that record evaluation. Everything lives under the 

With policy management, rules about which packages are safe and acceptable are automatically enforced on every package at the registry, before they reach your build environment. Changes in threat intelligence or updates to policies automatically trigger re-evaluation so your risk exposure is always current. 

This feature automatically checks incoming packages and those already in your repository against known vulnerabilities and malicious packages. Detection is powered by 

, which triggers new evaluations as new threat intelligence hits the data feed.

This feature helps compress the gap between when new threat advisories are published and when organizations evaluate packages against those advisories. Because this feature runs continuously, teams don’t need to wait for the next scheduled scan, a delay that widens their exposure window.

Cooldown policies became generally available for npm and Python in Q2, and in Q3 we expanded support to six more formats: 

. You can create cooldown policies via the web app, API, or Terraform. These updates extend the reach of cooldown policies beyond application libraries to include container images and Rust crates. 

This is an improvement in the policy editor that flags Rego problems as you write. On save, the web app and API reject disallowed builtins (such as 

), type mismatches, incorrect argument counts, and unsafe or undeclared variables. The web app editor also warns when a policy is missing `package cloudsmith` or a match rule, highlights malformed Rego inline, and autocompletes schema field names.

Catching mistakes while you type means fewer policies that silently fail to do what you expect, and a shorter learning curve for teams new to Rego.

Download vulnerability findings from the web app

 on a package’s Overview tab to export every vulnerability and malicious package record matched to it as JSON. This data is also available from the Packages Vulnerabilities List API endpoint.

Simplify incident investigation and compliance audits by allowing security teams to send findings to a ticketing system, SIEM, or auditor in one click, without writing an API script.

Hardened images tab for configuring upstreams

Upstream configuration now supports Docker Hardened Images (DHI), Chainguard Containers, and WizOS. The DHI Community and Chainguard Containers Free tiers come pre-configured. For paid tiers, the proxy URL is filled in for you, so you only name the upstream and add credentials.

Making hardened images quick to proxy lowers the cost of adopting them, and every pull is cached, logged, and subject to your policies.

Libraries tab for vendor-curated package registries

 tab quick-configures library registries, which include vendor-curated feeds of open source packages that may be pre-vetted, rebuilt from source, and security scanned. Currently, this feature supports Chainguard Libraries (Maven, Maven Remediated, npm, PyPI, PyPI Remediated) and RapidFort Curated Libraries (npm).

Teams can adopt curated, rebuilt-from-source packages as a drop-in upstream and manage them alongside public upstreams and private packages in one place.

Go upstreams for any GOPROXY-compatible proxy

Go upstreams can now point to any GOPROXY-compatible module proxy, in addition to the public mirror at 

. That includes private proxies such as the Buf Schema Registry (BSR).

This feature gives you one control point for all Go dependencies, with caching, policy, and logging, instead of managing multiple GOPROXY settings.

CLI v1.19.0: automatic OIDC and Docker credential discovery

The Cloudsmith CLI automatically discovers OpenID Connect (OIDC) credentials for all major CI/CD platforms and includes a Docker credential helper to automatically authenticate to Cloudsmith registries. This eliminates the need for static API keys in CI/CD pipelines.

Long-lived API keys stored as CI secrets are one of the most common ways credentials leak. With OIDC discovery, there’s nothing to store, rotate, or leak.

The Cloudsmith CLI now ships as a standalone, self-contained binary for Linux, macOS, and Windows, eliminating its dependency on a local Python environment.

This means that pipelines no longer break when a runner’s Python version changes, and installs are faster and identical on every platform.

CLI v1.21.0 to v1.26.0: Nix, Cargo and pnpm helpers, and repo admin

Multiple updates to the Cloudsmith CLI with this changelog include:

: Treats Nix as a first-class format and users can push Nix packages and manage Nix channel upstreams

: Includes support for Cargo and pnpm, plus a generic helper that prints a credential as JSON for any script

: Cloudsmith can now push a Debian package by reading the 

: SSO and OIDC sessions work in more places: encrypted file-based keyrings, new keyring environment variables, and 

: Keychain prompts no longer reappear after every token refresh

Package logs are now available in the web app under the 

 tab. This per-package audit trail allows users to track package actions, including copy, delete, hard delete, move, policy violation, quarantine, restore, resync, sync, and tag changes.

This update speeds up incident response and gives you ready-made compliance evidence.

Client logs show the full request chain behind a download

Client logs now capture format-specific metadata for every supported format, including metadata fetches and redirects, not just the final file download.

This helps you understand which version a build resolved and where that decision occurred. It also accelerates debugging questions around package selection and how certain packages made their way into specific builds.

Downloads, token use, and client logs in the Broadcasts app

 app now shows how published packages are consumed: counts of broadcasting packages, entitlement tokens active this billing cycle, usage by repository, and top downloads. A world map and table break down delivery by country, and a filterable client log stream shows individual requests.

For users that distribute software to customers, this improvement puts adoption and per-customer usage data in one place. That can help with product decisions and license compliance, and makes unusual entitlement token activity easier to spot.

Cloudsmith can now serve as a public or private Nix binary cache. Teams that use Nix can push packages with the native 

 command, and Cloudsmith signs store paths with the repository's Ed25519 key when they’re read, so key rotation takes effect immediately and multiple keys can be valid at once. Nix upstreams proxy and cache NixOS release channels, one upstream per channel.

Everything Cloudsmith shipped in Q3 2026

What happens when a new vulnerability emerges for a package you already used in a build? If you don’t find out about that new vulnerability right away, then your production system is at risk until the next security scan runs. Scan results provide a point-in-time snapshot, but they’re only valid until the next CVE comes out. Currently, we’re seeing an 

 solves this problem using a near-real-time threat data feed to power a lightweight lookup rather than an in-depth scan, allowing it to run as new advisories emerge. If you scan daily, continuous risk detection can reduce a 24-hour risk window to as little as five minutes.

Scanning is a package-centric process. For every package in a repository, the scanner needs to schedule a scan, prepare the package to scan, perform the analysis, and then store the result. This is a resource-heavy process, making it expensive and time-consuming. Typically, that means packages get scanned once on upload and don’t get evaluated again until a daily or weekly scheduled scan occurs, or someone initiates a manual scan. In practical terms, this means that scan results go stale quickly because they are only relevant as of the time that the most recent scan occurred.

Because scanning is such a valuable tool, the natural reaction may be to run scans more frequently. There are several technical reasons that make scanning more often a challenge.

The first is a cardinality problem. Scan time scales with the product of the number of packages in a repository and the number of CVEs that have accumulated since the last scan. Enterprise-scale repositories are so large (e.g., tens of thousands of packages) and CVE lists are so long (e.g., hundreds or thousands, depending on the scan schedule) that a full rescan can take longer than the interval between new threat advisories.

Another issue is that scanning images increases the scanners’ workload. Each image contains a bundle of packages, e.g., the base image, installed dependencies, layers, and the scanner needs to unpack all those elements, identify them, and then scan each one. A base image package also gets scanned in every downstream image that includes it, which further compounds the cardinality issue.

Because scanning tools can’t run continuously, teams often use multiple different scanners at different development stages, e.g., at source, build, test, and runtime. Different tools often use different output formats and lack a common data store for scan results, so results from a source-stage SCA scan may not be able to share results with a build-stage SCA scanner. The result is a visibility gap that prevents teams from having a holistic view of their environment’s overall risk level.

Continuous risk detection uses matching to enable real-time security evaluations

Where scanning uses a package-centric approach, continuous risk detection uses matching, which is vulnerability-centric. Packages contain a unique package URL (PURL) that details the package name, ecosystem, and version. Threat advisories carry PURLs too, and continuous risk detection uses a lightweight database lookup to match the PURL in the threat advisory to packages entering or already in a repository. There’s no need to perform a complete in-depth scan, which means that the matching process can run continuously as new advisories get published.

Because matching is less resource intensive, it can run at the artifact registry layer. This is important because the artifact management platform plays a unique role in the software development lifecycle; it evaluates every package and dependency that enters the development environment, and interacts with every stage of the development process.

An artifact manager provides broad and consistent visibility across the entire development environment. It keeps a persistent set of metadata for every package in the repository over the lifespan of the package and knows every build that consumed a package. When a new CVE emerges, continuous risk detection can look at any package you’ve ever used and determine if there’s a match. Standalone security tooling lacks a persistent repository and can’t make the same determination.

Furthermore, because continuous risk detection is a native capability of the Cloudsmith platform, it’s able to trigger 

security policies when it detects a CVE match. You can use that same persistent repo data in custom policy-as-code security policies, making the two features intrinsically connected in the platform. This is another reason to use Cloudsmith as the control plane for software development.

The main limiting factor to both scanning and matching is that they rely on known CVEs, so zero-day threats remain a concern for security teams. In Cloudsmith, you can augment continuous risk detection with another proactive security policy: a 

. Cooldown policies hold newly released packages for a set period of time (e.g., 3-7 days) to allow threat intelligence researchers to vet them, helps to bridge the zero-day gap, and contributes to a defense-in-depth security posture.

Continuous risk detection matches threat data to new packages at ingest and continuously thereafter when new threat intelligence lands. Powered by 

, the data feed for continuous risk detection provides near real-time threat evaluations for every package in your repository.

 to learn more about continuous risk detection and how it can improve your security posture.

How continuous risk detection replaces point-in-time scans with real-time monitoring

Cloudsmith provides a control plane at the registry layer, enforcing policies against any ingested artifact to bolster your security posture. Here, we dig into the mechanics of the specific Cloudsmith capabilities that make enforcement at the registry work, and what makes each one meaningfully different from what you can do with a CI gate or a standalone scanner.

Cloudsmith Blog

Why enforce supply chain security at the artifact registry

Tensorlake SDK npm package compromised

OIDC removed long-lived credentials from your pipelines. What about your laptop?

Cloudsmith expands support to Nix

Everything Cloudsmith shipped in Q3 2026

How continuous risk detection replaces point-in-time scans with real-time monitoring

How Cloudsmith security features work: policy, risk detection, and the audit trail

Simplify repository structure with connected repositories

Trust your software supply chain from ingestion to production

Keyv and Cacheable npm packages compromised in active supply-chain attack

The evolution of Shai-Hulud-style worms

Cloud Native Digest - July 2026