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

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.

Jason Myers

Technical Content Marketer

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

On August 4, 2026, a self-propagating worm began 

publishing malicious versions of the npm packages keyv and cacheable

, is still developing as we publish, and the list of affected 

 packages has grown through the day to 2,236 package versions. Below we cover what we know so far, how to check whether your organization is exposed, and the controls that stop this class of attack from reaching your builds.

Beginning around 10:53 UTC on August 4, an attacker started pushing malicious releases to legitimate, well-established 

 packages. We know these were not a set of newly published typosquatted packages; the attacker is publishing new 

 of real packages that teams already depend on.

The scale of this attack is significant - tracking so far points to roughly 

 published across them. Several packages received a dozen or more malicious versions in a matter of hours, and new versions were still appearing past 13:20 UTC.

The affected packages sit deep in the JavaScript dependency graph. 

 are transitive dependencies of a large range of common tooling, so most teams that install them never explicitly chose them directly. Weekly download volume for some of these packages rivals the most popular libraries on 

, which gave the campaign a very large potential blast radius.

The activity carries the hallmarks of the 

. The malicious payload is delivered through install-time lifecycle (preinstall) scripts. Once executed on a developer or CI machine, it harvests credentials and tokens and uses any recovered 

 publish tokens to push malicious versions to other packages the compromised account controls. That self-propagation is why a handful of initial compromises turned into hundreds of packages within hours.

It’s also important to note that if you’re running 

, released roughly a month ago, it no longer runs lifecycle scripts by default. Organizations that have upgraded and not re-enabled script execution are substantially protected even if a malicious version was pulled, because the payload never runs on install. However, teams still on older 

 clients, or that have explicitly enabled install scripts, do not have that inherent protection.

Exposure comes down to two questions: did you install an affected version, and could it run on install?

 Compare the packages and versions in your lockfiles (

 against the current indicators. Community trackers are maintaining live lists; the tagged dataset at 

 are both being updated as the campaign expands. Because the affected set is still growing, treat any single snapshot as a lower bound and re-check.

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.

 The malicious versions were published in a bounded window on August 4. A version of an affected package that predates that window is not part of this campaign. Confirm the specific version, not just the package name.

Check whether install scripts can execute.

 client version and whether lifecycle scripts are enabled in your environments. If you are on 

 with scripts disabled by default, an affected version that was pulled but never executed represents materially lower risk.

 If a malicious version could have run in a developer or CI environment, rotate 

 tokens, cloud credentials, and any secrets that were reachable from that environment, and review recent publish activity on your own packages.

Search your Cloudsmith registry for any cached versions & quarantine. 

If your organization doesn’t have a cooldown or malware policy in place, there's a chance a malicious version was already requested by a developer or pipeline and cached in Cloudsmith - search for any affected versions and quarantine them.

If you find only pinned references in old, dormant projects, the immediate risk is usually low, since a locked dependency tree will not pull a new malicious version on its own. The real exposure is a fresh install or a lockfile refresh that resolves to a compromised version.

This attack is just another example of why pulling directly from a public registry into your builds is a risk worth removing. Cloudsmith sits between the public registry and your developers and pipelines as a single, policy-enforced control point, which changes the outcome in three ways.

While there are many client-side cooldown solutions built into native package managers, this can often be difficult to manage at scale for enterprises. Regardless of client version or script settings, Cloudsmith moves enforcement to the server-side by removing newly published upstream versions for a defined window before they become installable. Attacks like this one depend on speed: a malicious version is published and pulled into builds within minutes or hours, then withdrawn. 

 means those versions are never served to your teams during the window when they are most dangerous, buying time for the ecosystem to flag and remove them.

 Packages flowing through Cloudsmith are scanned for malware and also matched against our comprehensive database of malware advisories. With 

, you can define policies that block versions flagged as malicious or matching known indicators. When a package is identified as compromised, the policy stops it from being distributed to any consumer behind Cloudsmith, without waiting for every developer to update a manual blocklist.

 Because installs resolve through Cloudsmith rather than directly from the public registry, you get one place to enforce controls, one audit trail of exactly what entered your environment, and the ability to answer "were we exposed?" from your own records instead of reconstructing it across every machine and pipeline. Cooldown and malware policies only protect what actually routes through them, so 

 is ensuring your package installs go through the proxy rather than reaching upstream directly.

By applying these safeguards in Cloudsmith, you can greatly reduce the likelihood of being affected by the frequent supply chain attacks we are seeing across the open source ecosystem.

Cristian Garcia

Senior Customer Success Manager

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

If time’s just a construct of human perception, does that mean all package managers interpret time differently? And what does that have to do with cooldown policies?

 help protect your software supply chain from zero-hour threats by holding packages for a set period of time to allow threat intelligence to catch up. But where does a package get held, and how does that impact how you configure your cooldown policy?

You can implement cooldown controls on either the client-side and on the server-side. This post highlights the difference between where the cooldown policy lives, and how that impacts your ability to implement and scale that policy. We’ll explore how they can be defined differently in various ecosystem package managers, and why all this flexibility actually might hinder (not help) the security posture of our software supply chain.

JavaScript developers most commonly pull 

 registry. The most popular Javascript package manager, 

, included the concept of a minimum release age (

 represents the number of days a dev must wait before they can receive a newly-released software dependency, as a single number unit. However, not all JavaScript package managers work the same way. The 

 client, for example, chose a completely different unit of time. We can see that 

 specifically treats cooldown (within the 

 registry also introduced the cooldown field 

) represents the configured cooldown period in 

) supports days and weeks in a more humanly-readable approach, similar to 

This leaves JavaScript teams in a situation where securing a polyglot Node.js environment requires a math degree and a cheat sheet! If your team wants to implement a cooldown policy and uses a mix of 

 (as only a few examples), you need to translate a basic 48-hour quarantine policy into days, minutes, seconds, and human-readable string tags simultaneously. This arbitrary config drift is more than a tedious task, it’s a genuine security liability. When security policies are this fragmented across tools running in the same language ecosystem, misconfigurations are more likely.

The Python ecosystem is similar to JavaScript when it comes to representations of time. Astral’s 

 package manager provided cooldown controls in 

. It uses relative durations, but also supports a bunch of other duration formats (inside 

The result in the Python ecosystem is a case of duplicate standards. While more modern, lightning-fast tools like 

 embrace highly flexible relative text strings, standard 

 leans heavily into the rigid syntax of ISO 8601. For security teams trying to enforce a consistent supply chain guardrail across a variety of developer endpoints and pipelines, this introduces a layer of translation friction. We aren't simply configuring the time window, we’re also managing entirely different syntactical philosophies from what was discussed in the JavaScript ecosystem - just to keep a volatile package at bay.

Package Managers with no support for Cooldown Policies

And that brings us to the lack of support for cooldown policies in many other popular language ecosystems. As of the time of writing, languages like 

 provide client-side support for cooldown controls in any direct configuration field.

In the absence of built-in cooldowns, devs without server-side or private artifact repository solutions rely on strict version pinning as their primary line of defence. But version pinning is a double-edged sword:

Pinning to an older version should (generally speaking) keep you safe from a zero-day compromise in today's release, but it leaves you exposed to older, known CVEs.

Pinning only works if you trust the version you are pinning. If you update your config to pin a newly released version and that version happens to be a compromised release from a hijacked maintainer account, well then, your client will happily download and index that malware regardless.

Without a cooldown policy acting as a quarantine buffer, devs updating their pinned dependencies are essentially playing Russian roulette with the latest release.

On a positive note, the open source supply chain is evolving all the time. Where cooldown controls don't exist today, they could very well exist tomorrow. What’s important to software developers and security teams is that we can curate or enforce security controls that seamlessly apply across the wide variety of languages and runtime ecosystems.

That’s where an artifact management platform like Cloudsmith comes to the rescue. The platform provides cooldown policy support for 

, with additional format support planned:

Cloudsmith supports cooldown policies in npm and Python

If time really is just a construct of human perception, package managers have certainly taken that philosophy to heart. But the real headache is trying to actually implement security controls in the real world. 

This is fundamentally a client-side crisis

We are forcing devs and their pipelines to rely on local, fragmented CLI tooling to enforce security policies that should be uniform. The fragmentation here is a massive vulnerability:

Different naming conventions and arbitrary time units across clients make universal configurations very challenging.

Some client-side tools allow granular exclusions, while others offer no cooldown protection at all.

While centralised registries like Cloudsmith work overtime to curate, scan, and secure upstreams, they need to account for rogue, outdated, or poorly designed local clients that bypass standard safeguards.

Trying to secure a polyglot codebase where the security posture of your entire pipeline is dictated by the weakest client-side tool in your stack is a logistical nightmare.

Cloudsmith solves this systemic headache by providing a single control plane for your entire software supply chain. By defining a universal policy that sits above individual ecosystems, you don’t waste time tweaking configurations across a wide range of runtimes. With Cloudsmith, you define the policy once, and enforce it across your entire workspace.


If you’re interested in learning more about Cloudsmith 

Nigel Douglas

Head of Developer Relations

How to configure time for cooldown policies

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 

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 (

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

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.

Policy management: Write policy against a breadth of risk signals

 is built on Open Policy Agent (OPA) and uses Rego as its written language. In Cloudsmith, the power of policy management comes from what you can write policy against.

Other enforcement approaches often rely on blunt, binary policies. This lack of granularity can result in blocking approved packages, which creates noise and disrupts developer workflows. For example, a binary control may block a package with a CVE score that exceeds a threshold. But CVE is only one of many potential threat signals. CVE severity tells you how bad a vulnerability 

 be. It doesn’t say anything about the likelihood of exploitability. Policy management lets you combine severity with EPSS scores. A package with a critical CVE with a 0.1% EPSS score and a package with a medium CVE currently being actively exploited are not equivalent risks, and your policies don't have to treat them as if they are.

Beyond vulnerability data, policies can evaluate against license type, upstream publish date, package age, custom metadata, and, for Docker images, SBOM contents. That constitutes a much broader range of signals for security teams to use when deciding whether a dependency belongs in their environment. Cloudsmith makes all that data available as policy inputs.

To aid with set-up, provide pre-configured policy templates covering the most common enforcement scenarios. Users can edit and amend these policies as their needs evolve. Legacy artifact management tools that claim similar policy-as-code capabilities added it by way of acquisition. This kind of bolt-on solution often forces users to manage admin configurations in multiple places. Cloudsmith policy management is native to the platform with all controls and options under the “Policies” tab. These policies also apply across Cloudsmith’s multi-format repos, so you can write a policy once and apply it globally.

Cooldown policies: Closing the remediation window

It’s impossible to predict what packages attackers will target next. So, when a new supply chain attack occurs against a package you depend on, what do you do in the window between when the attack begins and a CVE surfaces? That’s the most dangerous time because you may pull a compromised package without realizing it. Without a cooldown policy, that package enters your environment unchecked.

 address zero-day threats by hiding newly published packages from the index for a configurable period (e.g., 3-7 days). Threat researchers typically identify and report malicious packages within the first few hours or days after publication. The cooldown window provides a default buffer for threat researchers to catch up. If no advisory emerges during the cooldown window, the package releases into your environment once it ends. For security-focused teams managing active CVE incidents, this is one of the more operationally specific controls in the feature set; it targets the exposure window directly, rather than just blocking on severity at a static point in time.

Continuous risk detection: Enforcement that reflects current threat data

Vulnerabilities can go undetected for years after a package is published, or a dependency that was clean on Monday may have a critical CVE attached to it by Thursday. Regardless of how long a package has been in your private repository, you need a way to check it against current threat data.

. Rather than rescanning packages on a schedule, Cloudsmith extracts metadata from each package at sync time and continuously matches it against OSV.dev. When a new CVE, EPSS update, or malicious package record lands in the feed, and Cloudsmith finds a match with a package in your registry, this triggers your policies to re-evaluate the package and take the associated action, e.g., quarantine.

OSV.dev draws on a wide range of data sources, including NVD, GitHub Security Advisories, ecosystem-specific databases like PyPI and RubyGems, and malicious package records covering npm, NuGet, PyPI, and RubyGems, among others. EPSS scores are embedded directly, making them available as policy inputs without any additional integration work.

The result is policies that evaluate against a live view of current threat data, not whatever the feed showed when the package first arrived.

Every policy evaluation Cloudsmith runs produces a decision log entry: what triggered, what data informed the decision, what action the policy took, and why.

In a compliance review, e.g., SOC 2 Type II, DORA, FedRAMP, PCI-DSS, or CRA, log data is the evidence that your controls are real and operating as specified. In an incident response scenario, it’s the audit trail that tells you what was in your environment and what your policies did about it.

Decision logs are queryable via API, which means they integrate into whatever reporting or observability tooling your team already uses.

Why these capabilities reinforce each other

These capabilities cascade into and connect with each other. Continuous risk detection updates the risk profile that policy management evaluates against. Policy evaluations, including cooldown windows, produce decision log entries. Decision logs close the audit gap that makes enforcement defensible in a compliance review.

Cloudsmith delivers a continuous control plane for safely consuming open source dependencies. That's the structural difference between a security program built on Cloudsmith’s security features and one that relies on point-in-time scanning and downstream pipeline gates.

 about what security enforcement looks like for your environment.

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

The software supply chain landscape changed forever in early-to-mid 2026. What began as a series of isolated credential-theft incidents quickly mutated into a highly coordinated, multi-registry, self-propagating 

 campaign.

By abusing trusted relationships, hijacking CI workflows, poisoning build caches, and even embedding execution scripts inside compiled native binaries, the threat actors behind this campaign (tracked as 

) bypassed traditional static scanner defences.

As of the time of writing, this is a somewhat complete, chronological teardown of the three distinct waves of this campaign: 

Shai-Hulud, Mini Shai-Hulud and similar worms

The Shai-Hulud worm lineage first surfaced in late 2025 as a direct credential stealer targeting the npm ecosystem. However, on May 11th, 2026, a highly automated, modernised variant called Mini Shai-Hulud struck with vastly expanded scope. While it heavily impacted npm, compromising more than 170 packages across the TanStack, Mistral AI, UiPath, and OpenSearch ecosystems, the worm simultaneously breached the broader software supply chain, orchestrating coordinated attacks against PyPI, RubyGems, Docker Hub, and even malicious extensions within VS Code.

Unlike the earliest waves of Shai-Hulud that relied specifically on stolen static developer credentials, Mini Shai-Hulud (believed to have been created by a different group to TeamPCP), gained entry to these diverse environments via entirely new approaches, like pull request workflow misconfigurations in GitHub Actions (as seen in the 

 compromise).

The basic workflow looked like this. An attacker submitted a pull request from a fork. This triggers a workflow that grants write access to the base repository's cache. The attacker proceeds to poison the cache with malicious payloads. Hours later, a legitimate maintainer merges a commit, triggering the standard release workflow. And this all concludes with the release run pulling the poisoned cache and executing the malicious payload invisibly.

Rather than exposing static tokens, the worm scraped live tokens directly from the GitHub Actions runner’s active memory (the 

Cloudsmith Blog

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

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

How to configure time for cooldown policies

Why enforce supply chain security at the artifact registry

Tensorlake SDK npm package compromised

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

The evolution of Shai-Hulud-style worms

Inside the AsyncAPI npm supply chain attack

How to use Cloudsmith as a dependency firewall

A dependency firewall gives your scanner better inputs

Dependency attacks start before your scanner runs

Cloudsmith credentials are now detectable by GitHub Secret Scanning