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

You can do everything right and still be impacted by a software supply chain attack.

 worm, and its variants, are recent examples of this. Compromised packages ran 

 scripts, that executed malicious code to exfiltrate keys and credentials before any scan in the consuming team’s pipeline ran. The worm then used those stolen credentials to inject malicious code into other packages in that maintainer account.

Organizations running code review, SAST, and SCA that were impacted by these attacks likely did everything right. The tools did the job they were designed to do. It’s just that the attack mechanism targeted a gap in the supply chain security ecosystem.

Teams now need to think about having a different control at each stage of the supply chain, so a package that gets past one control meets the next. Each tool covers part of the chain. Defense in depth comes from connecting them. Detection tools find risk and can help prioritize remediation, enforcement points act on detection findings, and the stack holds when a finding from one tool reaches a control that can stop the package before it’s used.

This blog series examines the software supply chain security ecosystem, identifies the primary tooling categories and where they run in the development lifecycle, and situates the role artifact management plays in relation to each category.

The development process sees code written, committed, built, published, distributed, selected, and run. Every exchange point in that process presents a gap and is a potential attack target.

Using AI agents to generate code introduces a potentially unreliable author to the development phase. This risk extends to ‘vibe coding’ or ‘citizen developers’ who may lack training or context around coding best practices and package selection when prompting agents. Any decisions made by AI agents or citizen developers cross your environment’s trust boundary the same way decisions made by your developers do.

Slopsquatting is like typosquatting but designed for AI agents. AI can hallucinate package names. Attackers can track naming trends in these hallucinations and proactively create malicious packages using those package names.

Attackers that compromise maintainer accounts target the 

 of open source software. If a maintainer contributes to multiple projects, a single attack can infect them all. These attacks often use social engineering to get maintainer account credentials. Typically, attackers have two paths for getting malicious code into the development environment. One, they use a stolen token to bypass the build stage and upload a malicious version directly to the public registry. Two, with access to the source repository, they can alter the contents of the build itself and publish it through the maintainer’s trusted build pipeline. In this situation, malicious packages can carry valid provenance and signatures, making them appear trustworthy.

Shai-Hulud-style attacks exploit default configurations in the security ecosystem. Package managers, such as npm, run install scripts unless explicitly told not to, and those scripts gain access to long-lived publish tokens that sit on machines.

Detection finds risk. Enforcement stops it.

There are two complementary aspects of software supply chain defense. One is detection and visibility. The other aspect is enforcement and the ability to act on detection findings.

Detection can happen in multiple locations, and those findings need to feed enforcement mechanisms that sit at a point where they can stop malicious packages before they enter developer environments. Endpoint protection tools sit on a single machine’s path and are quick to roll out, and they cover installs that never touch a shared registry. They also depend on being installed, updated, and configured the same way on every machine, which gets harder as a company grows. A platform such as an artifact manager sits where most paths converge, so one policy covers every laptop, runner, and agent that routes through it. Most organizations need both: the platform as the default path, and endpoint controls for whatever goes around it.

The ecosystem has two functional concepts that underpin the whole software development lifecycle and six stages that follow, roughly, the order of software development, from writing code to running it. Modern development is continuous and iterative; multiple build processes can run at different stages at the same time. Each stage ends at a handoff, and each handoff is a place where a threat can slip through. Many tools run in more than one stage, so where a given tool fires depends on how your organization configures and triggers its build pipelines. The general shape holds, though, and it shows where each category does its job and where its reach ends.

The teams responsible for each stage select and configure tools for that stage, and some types of tools might have roles in multiple stages. The breakdown below describes the threats and tools common in each stage and discusses how artifact management adds to and interacts with the tools already there.

Functional concept 1: identity and organization security

: Many of the largest and most recent supply chain compromises started with stolen credentials. Phished maintainer accounts, leaked CI tokens, and long-lived publish keys left on a build runner allow attackers to act as someone you trust. The self-replicating worm campaigns of 2025 and 2026 spread because each account compromise stole the tokens it needed to publish the next one.

: Identity tooling makes the people and systems that produce your software hard to impersonate. Elements of identity management include single sign-on, phishing-resistant multi-factor authentication, scoped permissions, and short-lived tokens that reduce the window attackers have to use them. Identity management applies to both human and non-human identities. A CI job that authenticates with a short-lived OIDC token leaves nothing long-lived behind. A malicious install script can only use a short-lived token while that job runs.

: Identity providers (e.g., Okta, Microsoft Entra ID), the identity and token/secret controls built into GitHub and GitLab, secrets managers, hardware security keys, and trusted publishing on public registries like npm and PyPI.

: Identity controls stop impersonation. They don’t stop a legitimately signed-in user, or a hijacked session, from pulling or publishing a bad package. Similarly, secret detection tools typically identify leaked credentials, but don’t indicate whether those credentials are still valid or need rotation.

: Your identity provider decides who someone is; the artifact manager decides what that identity can pull and publish. An artifact manager sits downstream and consumes identity from your identity provider (IdP), adding its own controls: role-based access, fine-grained publish and consume permissions, and OIDC authentication for CI so pipelines don’t need long-lived credentials.

Functional concept 2: detection and analysis

: Risk hides in first-party code and in third-party dependencies. Those risks include known and unknown vulnerabilities, malicious packages, leaked secrets, unsafe code patterns, and licenses you can’t or don’t want to ship. Your first-party code, whether written by developers or AI agents, is usually the smaller share of what ships. The rest is third-party dependencies.

: Detection tools find risk and report it. The same scanner can run in the IDE, on a pull request, in CI, and against a registry, and its output at every one of those points is a finding. That visibility is how teams learn what’s wrong, and most of the security tooling teams already own sits here.

: Software composition analysis (SCA), static application security testing (SAST), secret scanning, malware and behavioral package analysis, reachability analysis, and license detection. Example vendors include Snyk, Semgrep, Socket, Endor Labs, and GitHub (CodeQL and Dependabot).

: Detection only stops something when you connect findings to a mechanism that can act on them. Scans are point-in-time assessments and a software bill of materials (SBOM) is an inventory until actioned. A package that was clean when it arrived can pick up a critical advisory next week, so dependencies you pulled a year ago need re-checking as much as the ones arriving today.

: Artifact management adds a place to act on detection findings for every package that routes through it: matching stored packages against vulnerability and malware intelligence, re-checking them as new advisories land, applying policy when there’s a match, and blocking or quarantining packages that fail policy checks. Your SCA tool keeps doing what it does best, assessing reachability, fix paths, and remediation pull requests, and the registry provides a place to proactively enforce those findings.

: Bad code gets written or slips past review, or someone tampers with the repository directly. The author might be a developer or an AI assistant so the authoring environment matters at this stage, too: IDE extensions, AI code generators and editors, and MCP servers can all run with a developer’s privileges, and a poisoned extension or hidden instruction file can misdirect an AI author.

: Tools at this stage govern first-party code before and as it’s committed. Branch protection, basic source control management (SCM) best practices, and required reviews keep changes from landing unchecked. SAST reads source code for patterns that lead to vulnerabilities, like injection flaws or hard-coded credentials. Secret scanning catches keys and tokens before they reach a shared repository. Commit signing shows that a change came from the source that claims it.

: SAST (e.g., Semgrep, Snyk Code, GitHub CodeQL, Checkmarx, Veracode), secret scanning (GitHub secret scanning, TruffleHog), commit signing (Git’s native signing, Sigstore’s gitsign), and source control platforms with built-in policy (GitHub, GitLab, Bitbucket, Azure DevOps).

: These tools scan the repository you own. Third-party packages arrive in 

 or a virtual environment, not in your source tree, so SAST and code review never see them. In other words, 

a dependency’s pre- or post-install script never shows up in a pull request diff

: SAST and code review cover the code you write, while artifact management covers the code you pull in. These two code paths meet during the build process. Some artifact managers integrate with IDEs so developers can see package data while they work, but source code security stays with the tools above.

: Whoever controls the build controls the output, and an attacker can feed a build malicious inputs, like a poisoned dependency or a tampered build setting, or compromise the build platform itself. The 

 attack in June 2026 turned a project’s own process against it. The attack used a compromised maintainer account to push commits into Red Hat repositories without review. Those commits added a GitHub Actions workflow that ran inside the project’s own trusted publishing pipeline. The pipeline built and published malicious versions of packages in the 

 npm namespace, and because the legitimate pipeline produced them, they came with valid provenance attestations.

: Build integrity tooling aims for builds that are hermetic (no unexpected outside inputs), reproducible (the same source produces the same artifact), and provable. The output is provenance: a record of which build platform produced the artifact, from which source, with which parameters, that someone downstream can check later.

: Hosted build platforms with provenance support (GitHub Actions, GitLab CI), container build tooling (Docker BuildKit), hardened build pipelines (Chainguard), and open frameworks such as SLSA, in-toto, and the slsa-github-generator.

 went into the build was safe. The Miasma packages were built and published by the project’s real pipeline, so their provenance was accurate. The problem was the code the attackers had already slipped in before the build ran.

: The build runs in CI/CD, not in the registry. Artifact management touches this stage at both ends. Going in, it’s the source of a build’s dependencies, so a governed registry controls the build’s dependency inputs. Going out, it ties each push to a specific pipeline identity through OIDC and stores the provenance the build produces alongside the artifact.

Stage 3: artifact signing and attestation

: This stage is where a build leaves the build process and enters distribution. The primary threat is that what consumers receive isn’t what the legitimate build produced, or wasn’t produced by the legitimate build at all. Stolen publish tokens are a common threat route: the attacker skips the build entirely and publishes a malicious version straight to the registry under the maintainer’s name. That’s how Shai-Hulud spread.

: Signing binds an artifact, and its provenance, to the identity that published it, so consumers can detect any change after signing. Trusted publishing replaces long-lived publish tokens with short-lived OIDC identity tied to a specific pipeline, which closes off the stolen-token route.

: Sigstore (Cosign for artifacts, with Fulcio and the Rekor transparency log), Notation, GPG signing, GitHub artifact attestations, and trusted publishing on npm and PyPI.

: A signature proves who published an artifact and that it hasn’t changed since. It doesn’t prove that the contents are safe. That’s what happened with Miasma – attackers worked through the project’s actual pipeline, so the malicious packages carried valid signatures and passed verification. A signature is only useful if something checks it before using the artifact, and that check happens downstream on the consuming side.

: Signing tools and trusted publishing create the proof in the build, and a registry is one of the places that can check that proof before anything uses the artifact. A registry can keep signatures and attestations with the artifacts they describe, add its own signature on distribution, and refuse artifacts that arrive unsigned or with provenance that doesn’t match an approved pipeline, when policy specifies.

Stage 4: registries and artifact management

: The public registries or CDNs serving your artifacts get compromised, or serve something other than what was published.

: Every registry stores and distributes artifacts. Artifact managers do more, enabling private registries to function as a control point: they verify signatures, keep artifacts immutable, cache upstream sources so builds don’t depend on the public registry staying up, and apply access and security policy to what goes in and out.

: Universal artifact managers (Cloudsmith, JFrog Artifactory, Sonatype Nexus), cloud provider registries (AWS CodeArtifact and ECR, Azure Artifacts, Google Artifact Registry), developer platform registries (GitHub Packages, GitLab Package Registry), and vendor-curated registries for hardened images (Chainguard, Docker Hardened Images).

: A registry protects what’s in its custody. It doesn’t govern how artifacts were written or built upstream, and it only covers the paths that route through it. A developer laptop pointed at a public registry and with no other endpoint protections in place receives none of the safeguards an artifact manager may provide.

: This is artifact management’s primary function: one place to store, govern, and distribute the formats a team uses – language packages, containers, and AI models – with immutable versions, access controls, and caching close to your builds. Public registries and vendor-curated registries for hardened images stay in the picture as upstream sources; an artifact manager proxies and governs them.

Stage 5: package selection and policy gating

: A developer, build, or AI agent pulling the wrong package: a misspelled package name (typosquatting), an internal package name hijacked on a public registry (dependency confusion), a name an AI assistant hallucinated that an attacker registered (slopsquatting), or a brand-new malicious version of a package you already trust. Install scripts increase the pressure to select a safe dependency because they run the attacker’s code before your code imports anything.

: Tools at this stage decide what’s allowed into your environment before it’s installed. A 

 evaluates each package request against policy and takes action on the ones that fail, blocking or quarantining them. 

 hold brand-new versions until the community has time to spot a compromise, which doesn’t depend on an advisory existing. Curated catalogs and hardened images narrow the set of approved components from the start. Package managers help too: pnpm 10 no longer runs dependency install scripts by default.

: Dependency firewalls, deployed on endpoints (Socket Firewall’s CLI), as proxies (Socket Firewall Enterprise, Sonatype Repository Firewall, Veracode Package Firewall, StepSecurity Secure Registry), or inside an artifact manager (Cloudsmith, JFrog Curation); dependency confusion protection; allowlists and curation; and hardened images and curated libraries (Chainguard, Docker Hardened Images, Minimus, RapidFort).

Jason Myers

Technical Content Marketer

Software supply chain security stack

Software supply chain defense in depth: A stage-by-stage guide

Two critical core PHP vulnerabilities, together known as PHP2Shell, were disclosed this week and emergency patches are available. The flaws sit in PHP itself, so any site, developer environment, or CI pipeline running an unpatched version of PHP is exposed.

This kind of vulnerability requires a fast patch. PHP comes into environments in lots of places - in base images, CI runners, developer containers, and open source package repositories. In this scenario, ideally you’ll want a single view of your dependencies, so you don’t have to do a search across fragmented tools.

When PHP hits an out-of-memory error, a flaw in how it handles memory lets an unauthenticated attacker run arbitrary commands or read sensitive data from server memory.

The flaws affect every PHP release from 5.4 through 8.5.11. 

PHP reported that they consider consider the risk highest for mod_php

. There is a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs.

See which PHP versions your teams pulled and stop affected versions from being used

Cloudsmith can be the source of truth for what packages came into your environment, by which users, and when. That gives you a clear picture of your exposure.

Search your Cloudsmith repositories and package logs for the affected PHP versions.

Patched versions are available, but 8.5.12, 8.4.27, 8.3.36, or 8.2.35. PHP 8.1 and earlier are end of life and will not receive a fix.

Block critical vulnerabilities automatically: 

Set a vulnerability policy that blocks packages with critical vulnerabilities. It applies as soon as an advisory is published and protects you against future critical vulnerabilities.

 When new threat intelligence lands, Cloudsmith re-checks all existing packages in your Cloudsmith repositories against your policies automatically.

 with Cloudsmith for a custom assessment of your software supply chain.

Meghan McGowan

Product Marketing Manager

Critical PHP vulnerabilities in PHP2Shell expose web infrastructure to remote code execution

an attacker compromised the popular Python package LiteLLM

, publishing version 1.107.0 to PyPI and pushing trojanized images to Docker Hub and GitHub Container Registry (GHCR). This is the second time we’ve seen an attack on LiteLLM, the first in March 2026.

If your organization pulled or installed 

 on or after October 21, rotate your cloud credentials, SSH keys, browser sessions, and AI provider API keys immediately. The malicious release executed a credential stealer designed to exfiltrate secrets and query LiteLLM databases.

Here is what happened, how to check your environments for exposure, and how to block compromised packages automatically using Cloudsmith.

At 11:39 UTC on October 21, an attacker uploaded version 1.107.0 of LiteLLM to PyPI alongside compromised Docker tags (

). The compromise occurred when stolen GitHub CLI OAuth tokens were used to access maintainer accounts, override branch protections, and trigger a release pipeline pointing to a lookalike repository.

Upon installation or execution, the package injects files into the Python 

). These files execute automatically whenever the Python interpreter starts and deploy a credential stealer targeting:

 and IMDS metadata), GCP service account keys, Azure CLI tokens, SSH private keys, and GPG keys.

 Keys for OpenAI, Anthropic, Cohere, and other providers stored in environment variables or configuration files.

 Upstream credentials stored in local or remote LiteLLM PostgreSQL tables (

 Saved credentials and cookies from Chrome, Firefox, Edge, and Safari.

The payload encrypted harvested secrets via AES-256-CBC and sent them to an attacker-controlled endpoint (

). Active abuse was observed within hours, as attackers tested stolen AWS credentials against LLM foundation models.

Follow these steps to confirm exposure across your developer machines, repositories, and CI/CD runners:

Check for LiteLLM images pulled from Docker Hub or GHCR on October 21 (tags 

Search your Cloudsmith repositories with exact package names to avoid false positives 

(format:python) AND (name:^litellm$) AND (version:^1.107.0$)

Review your Cloudsmith client logs to identify which developer machines or build agents fetched version 

 Check this even if the search returns nothing. Upstreams set to proxy only serve packages without storing them, so those packages won’t show up in search.

Remove installations and rotate secrets: 

 ran in any environment, remove it immediately. Rotate all reachable AWS, GCP, Azure, and AI provider API keys, as well as SSH keys and database passwords. In Cloudsmith, quarantine the package rather than deleting it, so you keep the download history for your investigation

Why AI development is speeding up the attack lifecycle 

AI in the hand of attackers is compressing the supply chain lifecycle. Threat actors write malware faster, target AI tools directly, and reach pipelines through automated agents. 

Attackers use LLMs to build malware faster: 

 analysis noted strong indication of LLM–assisted code generation in the payload, allowing the attacker to iterate rapidly on multi-platform malware.

Packages like LiteLLM sit between applications and LLM providers. Compromise one and you reach upstream API keys, database credentials, and cloud infrastructure in a single step.

Agents install packages at machine speed: 

As engineering teams adopt autonomous AI coding tools and automated CI/CD pipelines, dependencies resolve faster than human review can keep up.

Block compromised packages automatically with Cloudsmith

Public registries supply most of your dependencies, and they serve the ecosystem well. But pulling straight from public registries into builds means a malicious version of a package can reach you minutes after it’s published. Cloudsmith sits between public registries like PyPI and your developers and pipelines, acting as a central control point that protects you in three ways

Many package managers have client-side cooldowns, but they are hard to manage at scale. Cloudsmith enforces the cooldown at the repository level, so they work regardless of client version or script settings, by holding back newly published upstream versions for a defined time window (typically a few days). Attacks like LiteLLM 1.107.0 depend on speed: a malicious version is published, it gets pulled into builds within minutes, and then it’s withdrawn from the public registry.

These policies act on public reports to the OSV malicious packages repository and other sources. Cloudsmith scans packages and matches them against our consolidated database of malware advisories. Cloudsmith 

 helps you block versions flagged as malicious, or matching known indicators. Once a package is identified as compromised, the policy keeps it from reaching any endpoint client, even after a cooldown policy window. This eliminates the need to maintain a manual blocklist.

Cloudsmith acts as the source of package dependencies for every developer, AI agent, and build pipeline across your company. As a central control plane that enforces controls, Cloudsmith produces a comprehensive audit trail of what entered your environment to answer questions like “Were we exposed?”.



If you'd like to understand your current exposure, 

LiteLLM 1.107.0 compromised on PyPI

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 (

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.

Tensorlake SDK npm package compromised

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.

Cloudsmith Blog

Software supply chain defense in depth: A stage-by-stage guide

Critical PHP vulnerabilities in PHP2Shell expose web infrastructure to remote code execution

LiteLLM 1.107.0 compromised on PyPI

Why enforce supply chain security at the artifact registry

Tensorlake SDK npm package compromised

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

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

The evolution of Shai-Hulud-style worms

How to configure time for cooldown policies

Inside the AsyncAPI npm supply chain attack

How to use Cloudsmith as a dependency firewall