By submitting this form, you agree to our 

A single typo is all it takes. A simple oversight and your whole application is handing out 404 errors like an episode of Oprah’s favorite things.

Bad actors leverage typos to introduce malicious code into the software supply chain. Once these packages get into your supply chain they can create a lot of damage. And it’s not just end users unable to access your application. We’re talking PR nightmares, data leaks, security threats, and all sorts of disruptive events. Having a central security and control plane for your software supply chain helps to identify and mitigate threats from typosquatting and other malicious software.

This post discusses typosquatting and how using an artifact manager can significantly mitigate these threats. We’ll look at some best practices for dealing with typosquatting and some Cloudsmith features that help you create a proactive security posture that doesn’t interfere with developer velocity.

: Typosquatting & Slopsquatting: Detecting and defending against malicious packages – Watch on-demand 

Slopsquatting and Typosquatting: How to Detect AI-Hallucinated Malicious Packages

To level set things, let’s define typosquatting. If you’re already familiar with the term feel free to skip to the next section.

 is a form of cyberattack where bad actors create packages that contain malicious code. They give these packages names that are similar to, or slight variations of known, trusted packages. They’re banking on developers making typing mistakes and not noticing them, essentially tricking devs into pulling these packages into their production environments where they can do damage.

: This is a variation of typosquatting driven by generative AI large language models (LLMs). These LLMs hallucinate package names that sound realistic, but do not actually exist. Bad actors identify these names and create malicious packages using the previously non-existent name, so the next time an LLM suggests the package, it exists, and it’s malicious. At present the standard defence against slopsquatting is to review PRs that may contain untrusted package names, and ensure all package pulls come from a trusted source. This article focuses on typosquatting, but it’s helpful to be aware of slopsquatting and how it fits into the typosquatting process.

These bad actors understand that speed in development is a driving force. This is especially true as developers experiment with new tools and technologies. It’s common for developers to see if a solution works first, then go back and think about security later. As a result, security struggles to keep up with the overall pace of development. It’s in this gap where typosquatting is at its most threatening.

Because anyone can upload packages to public open source registries (we’re talking about places like npm, PyPI, Maven Central, and the like), bad actors have ready access to distribution platforms for their malicious packages. Maintainers of these public registries may not have the time or authority to remove malicious packages. Plus, bad actors can upload packages faster than maintainers can address them.

That means the end user takes on the security burden by default. Developers benefit from an artifact manager to act as a firewall between public registries and their development environments. An artifact manager, like Cloudsmith, functions as a control plane for the entire software supply chain.

An artifact manager determines what enters, moves through, and leaves the software supply chain. It proxies packages from public registries and caches them in a private registry. Setting that private repo as the default location for package pulls ensures consistency across a development team and/or organization. It creates a private repository of known, trusted, and secure artifacts.

Why does all this matter for typosquatting? When developers default to public registries and pull directly from them for all their builds, they introduce the risks of typos or mistakes that could pull a typosquatted package into their environment. Pulling from a private repo in an artifact manager ensures you pull the same package every time.

Simply having a private repo does not make your packages secure. This is where security policies come into play.

The first time you push a package of any kind to Cloudsmith, the platform scans for malware. 

 have access to additional security features that detect package vulnerabilities and malicious packages. This includes scanning packages against trusted third-party databases, e.g., Open Source Vulnerability (

, which tell you what, if any, vulnerabilities exist for each package. It also uses Common Vulnerability Scoring System (

), and Exploit Prediction Scoring System (

) to score those threats and provide information about the severity impact of those vulnerabilities.

You can use this information to create your own policies that suit your security needs. For example, you may want to quarantine some packages. Others you may want to tag. You can build automations using these actions and policies to support a scalable security posture. Learn more about the current EPM actions 

Regarding typosquatting, qualified plans provide you baseline package health information before you ever create a security policy. A baseline understanding is not the same thing as proactive prevention, so let's take a look at how to begin addressing typosquatting from a policy perspective.

Creating a proactive anti-malware posture

Detection is only as effective as the policy that supports it. To secure the software supply chain without slowing down engineering, organizations need more than just scans. They need systemic governance.

 (EPM) lets you define, interpret, and take action on identified security threats. This translates into the implementation of transparent, automated, and scalable standards that protect the build process while remaining invisible to the developer. What does this look like in practice? Let’s look at a couple different options.

Assume you need to pull in the latest version of the PyPI 

 package. It has a generic name and could easily be typosquatted. There’s a known malicious package called 

. No doubt its author was banking on the fact that developers who forgot the ‘q’ in the package name would load this cryptomining malware into their development pipeline.

Let’s say that because you know this malicious package exists, you want to create a policy to explicitly target it.

An EPM policy to do this starts with the following code:

That policy looks for packages with the exact name 

. If it finds a match, you can define what action you want Cloudsmith to take later in the policy.

: You know the exact package you want to limit and the policy does that.

: You limited the policy to look for one specific malicious package, but others may get through.

package is really important to your work, another approach would be to limit other likely spelling variations that a typosquatted package may take.

You can update the policy in approach 1 to include an array of potential package names.

: You identify the known malicious package, and you proactively identify any other, similar packages that are likely to be problematic.

: This approach isn’t scalable. You would have to become an active threat researcher to properly maintain this policy. It’s also a very narrow policy focused on one specific package.

The first two approaches take a package-centric view of security. And really, they’re both reactive. While both will help you keep typosquatted packages out of your development pipeline, they don’t conform to the principle of least privilege.

Enterprises need a more comprehensive and scalable solution and least privilege does just that. The idea is to define what you 

want to use in your software supply chain and to allow only those packages. You set up rules to deal with anything that doesn’t agree with your policy.

The primary concern with typosquatted packages is that they contain malware. So, in this case, you want a policy that allows the things you 

 want (safe packages) and flags the things you 

 want (malicious packages). A proactive, scalable policy flags all known malicious packages and lets you take whatever actions are appropriate for your organization on them.

This is a simple, straightforward policy that identifies all known malicious packages. In the OSV database, packages with malicious code receive a “MAL-” identifier. For example, the ID for the 

. This policy compares the packages in your Cloudsmith repo with the OSV database and flags all matches with a “

There’s a broad community that, in effect, maintains the OSV database. Relying on this crowdsourced database is much more scalable, reliable, and ultimately accurate than trying to track down threats on your own.

: Scalable, applies principle of least privilege, relies on trusted third-party data for comprehensive scanning.

: Automatic scanning only occurs when a new instance of malware hits the source databases. If you are aware of a new example of malware before it appears in one of the source databases you may need to use one of the other approaches as a stopgap.

There’s one more scenario worth considering (for now) related to typosquatting. What if you already have a typosquatted package in your software supply chain. This may be a dependency that pre-dated current policies, or something that was a temporary exception that the team forgot about. Or perhaps someone found a bit of malicious code in a package that went unnoticed and was previously deemed safe.

Regardless of how it ended up in your supply chain, once knowledge of a compromised package hits the OSV database you want to know if it impacts your software supply chain. For most artifact managers, you would need to initiate a manual scan of your repos. Sure, you can set up alerts for OSV updates and/or schedule scans, but those are the kind of maintenance burdens that users want to avoid.

 feature. As mentioned above, Cloudsmith does an initial security scan when first pushing packages to the platform. Continuous Security, however, checks the source databases (i.e., OSV, Trivy) every hour. When it detects a new vulnerability or malicious package, it looks at your repository to see if it contains anything that may be affected. If so, Continuous Security triggers a scan of your repository against your EPM policies. This process happens automatically so you don’t have to schedule checks or scans.

The constant push to accelerate software development increases potential security risks to developer software supply chains. Bad actors create malware faster than security professionals can identify it. Taking proactive security measures mitigates the risks posed by malicious typosquatted or slopsquatted packages. This will become increasingly important as AI-generated code proliferates more builds.

Utilizing an artifact manager, like Cloudsmith, allows organizations to create policies around package consumption and implement automation for how to handle malicious packages when they appear. By acting as a centralized control point for all package consumption within your organization, Cloudsmith enables a proactive, scalable, and transparent security posture that allows developers to work fast and securely. In the speed vs security tug-of-war, Cloudsmith provides the middle ground that caters to both sides.

Want to see how Cloudsmith can help your organization? Book a 

Jason Myers

Technical Content Marketer

Protect your software supply chain from typosquatting with Cloudsmith

 know your LLM-generated code? LLM-powered copilots now write a lot of code, and they tend to suggest new dependencies your organization may not have used before. Without systematic security checks, you’re at risk of a hallucination exposing your production systems to a supply chain attack. Our increased reliance on open source and other third-party code increases risk to your builds. AI-generated code exacerbates those risks.

Let’s talk about how Cloudsmith secures your AI-generated code. By leveraging policy-as-code, private repo caching, and other best practices, Cloudsmith helps software development teams adopt a “verify and then trust” architecture, balancing AI-assisted software development with the need to defend system integrity.

Stop LLM hallucinations from breaking your build

LLMs are a great example of an untrusted contributor. They generate code without a complete understanding of your internal security standards. Their code may reference non-existent packages in a phenomenon known as AI hallucinations, and they may pull in malicious dependencies, created via a new attack vector dubbed slopsquatting. Cloudsmith’s 

 revealed that 79% of professionals believe that AI will exacerbate open-source malware threats, including typosquatting and dependency confusion.

The traditional "trust, then verify" model is no longer viable, because there is no true human intent behind an LLM’s package selection. Only 67% of developers review AI-generated code before every single deployment, per the 2025 report. To ship AI-generated code safely, we recommend moving to a "verify, then trust" architecture. This means treating every AI-suggested dependency as a potential threat until it passes a programmable gate.

Cloudsmith acts as that gate. By sitting between your LLM-powered copilots and your package ecosystem, we provide the metadata layer and policy enforcement needed to ensure that AI-generated code only utilizes verified, licensed dependencies within your private, controlled repositories.

Here is how you use Cloudsmith to stop AI-induced challenges at the front door.

The role of programmable security policies

What does “good” software supply chain security look like? It should do a few things:

Builds pull packages from trusted sources.

Scan new dependencies for malware and other vulnerabilities.

Automate blocking vulnerable packages from production environments.

Check package license(s) before it enters a build.

Continuous and systematic performance of these tasks at scale for end-to-end protection.

When you introduce AI into the equation, these tasks become more important. Implementing automated security processes and policies is the best way to make sure they happen.

The tradeoff between power and simplicity is one developers often face. “Checkbox security” is simple and straightforward, but it has its limits. You set policies via UI, using checkboxes, radio buttons, and other basic interface elements. These security interfaces are easy to understand, but they’re static and are not fully customizable to the user, organization, or project. Limited options and functionality mean that checkbox security doesn’t scale for enterprise-level development. It’s hard to do things like apply unique or fine-grained security policies to different projects, teams, environments, formats, and contexts.

Contrast that with policy-as-code where you get granular control over security policies, which is an inherently more scalable approach. 

 (OPA) is an industry standard for policy-as-code. It pairs with the Rego language to define rules for software usage and consumption. While Rego introduces a learning curve, OPA’s benefits are an enterprise-level industry standard.

 acts as an OPA engine so you can use the same 

 you may already be familiar with to create policy-as-code controls in Cloudsmith. You use Rego to create universal, baseline policies for every artifact in your Cloudsmith repos.

With EPM and Rego, you can create custom rules for specific repos, projects, or applications that cater to fine-grained security needs. EPM policies can evaluate SBOM data to ensure end-to-end consistency throughout your data pipeline. Our 

 highlights some of the different approaches to building policies, and serves as a great starting point for creating your own. We also developed the 

 for EPM, you can enforce an organization-wide requirement for a package with a specific version range. The policy evaluates the version of a package against a specified package version. It then triggers an action, like quarantining the package, if the version of the current package being evaluated is older than the specified package version.

Cloudsmith functions as a central source of truth for all your development packages and artifacts. From a security perspective, it functions as a gatekeeper, blocking or quarantining malicious, vulnerable, or non-compliant packages, in accordance with your policies, before they enter your build systems. When you pull packages, you always pull them from Cloudsmith, which makes sure they meet your security requirements.

AI-generated code introduces new complexities to securing your software supply chain. Discover how Cloudsmith can help automate the way you secure AI-generated code at enterprise scale with a 

Cloudsmith Blog

Protect your software supply chain from typosquatting with Cloudsmith

Securing AI-generated code with Cloudsmith