By submitting this form, you agree to our 

A practical guide to AI artifacts and LLMOps

Securing non-deterministic systems

The software supply chain is more complex than ever. Open source, containers, and now AI models form a growing and complex web of package dependencies that power software development. Developers have a lot of options and flexibility when building software, but this convenience also comes with risk. More dependencies expand the attack surface of a build and create long remediation cycles.

Vulnerabilities often emerge after something is already in production. Efficient remediation requires a strategy that balances two critical needs: intelligence and control. Your ability to maintain applications and reduce the impact of vulnerabilities requires you to 1. know what to do, and 2. have the right tools to do it.

Let’s look at a strategy that helps engineering teams build, secure, and ship software faster and more safely. We’ll see how Endor Labs provides the intelligence and Cloudsmith provides the point of control to efficiently remediate software vulnerabilities.

It’s not enough to simply know that vulnerabilities exist. You need to understand the different ways to remediate those vulnerabilities and the impact those fix options may have. Endor Labs provides the deep analysis required to understand what is actually happening inside your code.

: It builds a complete graph of your software, including source code, dependencies, and container images.

: Rather than just listing vulnerabilities, it uses 150+ risk signals, like maintainer activity and security practices, to help you decide which components to trust.

: It identifies which vulnerabilities are truly reachable at the function level, allowing teams to ignore the ‘noise’ and focus only on risks that can actually be exploited.

: Another layer of technical decision-making, this lets developers see the downstream impact of each upgrade option, anticipate breaking changes, and plan accordingly.

Once you identify your preferred fix with Endor Labs, you can use Cloudsmith as a ‘point of control’ and the single source of truth for your software artifacts.

: It provides the system of record to curate, proxy, and inspect every package and container your developers use.

Cloudsmith scans packages when they first enter the platform by default. 

 let developers establish clear guardrails around package management. Built on industry-standard Open Policy Agent (

) and using its declarative language Rego, policy management from Cloudsmith provides policy-as-code flexibility and scalability within your Cloudsmith repositories. Cloudsmith 

 on vulnerabilities to quickly identify new threats and emerging risks to the artifacts in your repository.

: It caches and secures every dependency, protecting your builds from public registry outages and ensuring every developer works with the same verified tools.

The overarching strategy is as follows: Endor Labs analyzes your codebase, identifying what vulnerabilities exist, the potential impact remediation will have, and where in your source code to address them. When implementing updates to fix those vulnerabilities, Cloudsmith provides a centralized and governed environment of managed artifacts, ensuring secure and consistent build processes across your entire organization.

The emerging AI software supply chain introduces even more complexity and potential conflicts and vulnerabilities to the software development lifecycle. But pairing Cloudsmith and Endor Labs extends to this area of development, too. They bring the same principles of open-source governance to the rapidly evolving world of AI models, MCP servers, and other AI dependencies.

, which brings standard software supply chain governance to AI/ML workflows. Proxy and host AI artifacts, like Hugging Face models and other ML package formats, just like you would with non-AI artifacts. Managing your AI/ML models alongside your code helps to eliminate blind spots and ensure consistent security and access controls across your environment.

Endor Labs applies governance and security controls to the code that integrates these AI/ML models. It gives you visibility into model provenance and risk factors that you can enforce with organizational policies. This includes the ability to report AI components in your SBOM.

Close the loop on software supply chain security

Cloudsmith ensures you consume secure and policy-compliant artifacts at the registry level, while Endor Labs provides deep code analysis, risk prioritization, and remediation workflows. Together, they keep applications and development teams working efficiently by reducing vulnerability noise, eliminating exploitable risks faster, and letting engineering teams focus on building quickly without sacrificing security.

With Cloudsmith and Endor Labs, security is built into every artifact your team consumes and every line of code you ship.

Jason Myers

Technical Content Marketer

Intelligence and governance in the software supply chain with Endor Labs and Cloudsmith

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 

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.

Are you looking for a complete strategy to protect AI-driven development workflows? Read our practical guide to

securing AI artifacts and operationalizing LLMOps

Cloudsmith Blog

Intelligence and governance in the software supply chain with Endor Labs and Cloudsmith

Protect your software supply chain from typosquatting with Cloudsmith

Securing AI-generated code with Cloudsmith