By submitting this form, you agree to our 

Explores AI-driven development, rising supply chain attacks, and new regulatory requirements.

2026 Artifact Management Report

In the current landscape of software development, the primary threat to the supply chain isn’t necessarily a lack of information – it’s a lack of action. Our 

 reveals a growing "enforcement gap": the dangerous interval between identifying a vulnerability and successfully applying a security policy.

While organizations are getting better at generating security data, they are struggling to operationalize it. Visibility without automated enforcement is a front-row seat to disaster.

The manual audit trap: Visibility without velocity

 they are vulnerable, but they struggle to tell you 

 is affected. While our report shows that identification speeds are improving, legacy infrastructure and manual processes hamper teams’ ability to act on that information.

One of the first questions after discovering a malicious artifact may be: “Who downloaded this and where did it go?”

The answer for many teams is far from instantaneous. Our survey found that 

 find it difficult to identify exactly which users or systems have accessed a specific compromised artifact, often requiring manual deep-dives into logs and system data for answers.

This manual toil is more than an inconvenience; it is a security risk. In a world of automated, AI-driven attacks, relying on human-speed investigations is a losing strategy.

Fragmented scanning: The “CVE-only” blind spot

Another major challenge contributing to the enforcement gap is toolchain fragmentation. Many organizations treat different types of threats as separate problems, using separate tools that don't talk to each other.

Our data indicates that while CVE scanning is becoming standard, many organizations are still missing logic-based threats and malicious package injections. In fact, 

 have a fully automated process for verifying the chain of custody or cryptographic origin of their artifacts.

When your security stack is a patchwork of third-party scanners and manual spreadsheets, deny-by-default governance is impossible to maintain.

The 24-hour countdown: Why the CRA changes everything

The enforcement gap is no longer just a security concern, it’s becoming a legal liability. The 

 introduces strict reporting mandates for any company selling digital products in the EU. Reporting requirements for the CRA begin in September 2026.

The notification windows for CRA compliance are narrow, requiring an “early warning” within just 24 hours of discovering an active vulnerability. If your team relies on manual effort to quarantine and remediate threats, meeting these legal timelines becomes a statistical improbability. To remain compliant, organizations must move away from static, compliance-only SBOMs and toward real-time, automated gatekeeping.

Cloudsmith was built to eliminate the friction between identifying a threat and stopping it. By providing a unified, cloud-native control plane for all your artifacts, we help you transition from reactive remediation to proactive governance.

 Don't wait for a scan to finish to decide on a package. Cloudsmith lets you write policies that can automatically quarantine any new dependency at the point of ingestion, ensuring nothing reaches your developers until it clears your specific security hurdles.

 We consolidate CVE scanning, malicious package detection, and license compliance into a single source of truth. No more parsing server logs; you get granular audit trails that show exactly who, when, and where every artifact was accessed.

 Cloudsmith automates the verification of digital signatures and maintains a cryptographically secure chain of custody for every binary. This ensures that what you build is what you deploy.

The velocity of modern software development demands infrastructure that can scale security as fast as it scales code. By automating the enforcement of your security policies, you don't just close the gap; you build a more resilient foundation for everything your team creates.

Get all the data on software supply chain security.

This post highlights a few of the challenges facing modern DevOps and Security teams. Download the 

, which contains data and analysis on the state of software supply chain security.

Jason Myers

Technical Content Marketer

Closing the enforcement gap: Why visibility isn’t enough for supply chain security

Figuring out a scalable way to secure AI continues to be a significant challenge for businesses everywhere. According to our 

 use AI to accelerate their software development cycles. We are building faster than ever, yet the infrastructure supporting this speed was largely designed for a pre-AI world.

As AI agents dictate the pace of production, they are also expanding software attack surfaces. Security practices that worked at human speed are buckling. At Cloudsmith, we see this as a two-sided challenge: securing the code AI writes (the output) and securing the models AI uses (the input).

Here is how the landscape is shifting and how a cloud-native approach to artifact management can provide the control necessary to future-proof your development.

AI agents prioritize functional results over security provenance. When an AI suggests a block of code, it can pull in new dependencies. When you factor in transitive dependencies, the situation gets even more complex. Our survey data shows that 

 feel very confident in the security of AI-generated code.

The problem: Manual validation is scaling poorly

 manually validating the dependencies introduced by AI. This “operational tax” chips away at the speed gains promised by AI adoption. Furthermore, AI is prone to hallucinating packages, suggesting names that don't exist, which attackers then register in public repositories to facilitate “

The solution: Automated quarantine and policy guardrails

Cloudsmith addresses this by acting as a sophisticated gatekeeper between your AI agents and the public internet.

 Instead of developers or AI agents pulling directly from public registries, everything flows through Cloudsmith.

 You can define rules (using OPA/Rego) that govern what you allow into your environment and what to block.

 Create policies that automatically quarantine packages that meet specific criteria. When an AI agent calls for a new, unknown package, you can inspect quarantined packages before they reach your development environment.

While AI generates code at scale, the models themselves don’t get the same scrutiny that regular binaries receive. Companies frequently store AI models in ad-hoc silos like local drives or unmanaged cloud buckets, detached from the standard software development life cycle.

Our findings show significant fragmentation in how companies handle AI models. Only 

 unify their model management with their standard artifact workflows. Meanwhile, 

 only perform basic integrity checks (like checksums), leaving them vulnerable to model tampering or malicious weight injections.

The solution: Models as first-class artifacts

To future-proof your AI initiatives, you must treat models exactly like other artifacts, like container images or npm packages.

 By using tools like Cosign within Cloudsmith, you can 

 your models. This ensures that the model running in production hasn't been tampered with and originated from your trusted pipeline.

 Cloudsmith scans the metadata and layers of these artifacts, ensuring that your “inputs” are as secure as your “outputs.”

Future-proofing: Building for machine scale

 isn't a temporary trend; it’s a fundamental change in how we build software. Traditional artifact managers – often on-prem and slow to update – cannot provide the visibility required for this new development velocity.

Cloudsmith helps you move from a reactive “trust then verify” posture to an automated, proactive “verify then trust” one. By centralizing code, containers, and AI models in a single, cloud-native platform, you gain the visibility needed to comply with international compliance standards and frameworks, like the EU’s Cyber Resilience Act, while giving your developers the freedom to move at machine speed.

Security should be the foundation for AI. By implementing automated quarantine workflows and a unified registry for models, you can reclaim the hours lost to manual validation and protect your organization from the unique risks of the AI era.

This post only scratches the surface of the shifts we’re seeing in the industry. Download the complete 

 to explore the full demographic breakdown, competitive findings, and our deep dive into the state of software supply chain security.

The AI speed trap: Securing the future of software supply chains

 that most developers in the AI space saw within hours: a simple 

 exfiltrated SSH keys, cloud credentials, Kubernetes secrets, API keys, crypto wallets, and more from any machine that ran it. He called it “software horror.” Given the scale, LiteLLM has 

The good news: this attack is exactly the kind of thing a well-configured artifact management setup is built to stop.

LiteLLM is an open-source Python library that acts as a universal API gateway for large language models. Instead of writing separate integration code for OpenAI, Anthropic, Google, and dozens of other providers, developers use LiteLLM to call all of them through a single standardized interface. It's a natural fit for any team building AI-powered applications, which is why it's become something close to infrastructure, with close to 100 million downloads per month.

That position in the AI stack, sitting between applications and every LLM provider, is also what made it an attractive target. A package with that kind of access to API keys and environment variables is worth compromising.

The threat group behind this, known as TeamPCP, didn't find a bug in LiteLLM's code. They worked their way up the supply chain: first compromising Trivy, a widely used open-source security scanner (

), then using that foothold to steal LiteLLM's PyPI publishing credentials. With those credentials, they uploaded two backdoored versions of LiteLLM directly to PyPI. This required no pull request, no code review, and nothing to inspect.

Standard integrity checks passed. The packages were published using legitimate credentials, so there was no hash mismatch, no suspicious metadata, no misspelled package name. The malicious versions were live for roughly three hours before PyPI quarantined them.

Three hours is a narrow window, but it's wide enough. And as Karpathy noted, the attack was only discovered because a bug in the malware crashed a researcher's machine.

The more unsettling detail is how far the blast radius extends. The contagion spreads to any project that depends on LiteLLM. This includes teams using it directly and anyone running 

 or any other package with LiteLLM in its dependency tree. Most developers have no visibility into what their dependencies depend on, let alone controls over it.

Three moments where this attack could have been stopped

The LiteLLM attack didn't require beating sophisticated defenses. It required developers pulling packages directly from a public registry with no organizational governance layer in between.

That's the gap Cloudsmith closes. It makes sure that your team doesn’t pull directly from PyPi without a policy check first.

Here's how that works in practice, mapped to the specific failure modes in this attack.

Cloudsmith acts as a proxy between your developers and upstream registries like PyPI. Packages don't arrive on developer machines directly from PyPI, they pass through Cloudsmith first, where your organization's policies apply. This one change puts every subsequent control within reach.

Apply a quarantine window to new package versions.

Cloudsmith lets you configure a cooldown policy that holds newly released versions in quarantine before they enter your environment and get served to your team. This gives the security community time to identify problems before your developers install anything. The policy applies organization-wide; it doesn't depend on individual developers remembering to check a release date or configuring pip correctly. The three-hour window that defined the LiteLLM attack becomes irrelevant if new versions don't reach your developers for 7 to 14 days.

Even on disciplined teams, a developer working quickly on their laptop might pull directly from PyPI. That's why your CI/CD pipelines should point to Cloudsmith independently of workstation configuration. Code that pulls a bad version locally doesn't survive the build pipeline because it gets caught before it reaches staging, production, or any shared infrastructure.

The LiteLLM attack is a useful reminder that AI tooling is software, and software has a supply chain. As AI agents take on more autonomous roles in development – installing dependencies, running builds, pulling packages – the same governance principles apply whether the consumer is a human or an agent. Controlling what packages enter your environment is part of running AI infrastructure responsibly.

If you'd like to understand your current exposure, 

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

How Cloudsmith can protect against the LiteLLM attack

Software supply chains are complex and increasingly fragile. For enterprise teams, managing an ecosystem of open-source packages, container images, and AI/ML models is no longer just a storage problem, it is a delivery and governance challenge.

Cloudsmith processes petabytes of artifact data every month for global enterprises. To meet these demands, we didn't just move our platform to the cloud. We built a genuinely cloud-native platform from day zero, using AWS to ensure that every artifact is fast, available, and trustworthy.

The architecture of trust: Why cloud-native matters

Many legacy artifact management tools were designed for a different era. Cloud-hosted is different from cloud-native. Cloud-hosted solutions typically begin as on-premise software that vendors retrofit to run on cloud servers. This architecture doesn’t eliminate operational maintenance; it shifts it from managing physical hardware to managing patching, upgrading, and complex high-availability configurations.

Cloudsmith is different. By building natively on AWS, we provide a platform that abstracts away infrastructure headaches.

: We handle all updates, patches, and scaling. Teams can stop firefighting infrastructure incidents and focus on shipping value.

: Our system uses multi-region redundancy by default. There is no single point of failure, ensuring that builds don't stall even if a specific region or load balancer goes down.

: AWS allows us to scale horizontally and vertically. Whether you are running ten builds or ten thousand, the platform maintains consistent performance without manual tuning.

That elasticity matters beyond traditional binary packages, too. As AI/ML models become standard supply chain assets, the architecture has to handle their size (often measured in gigabytes) without a separate delivery strategy.

Performance at the edge: Global delivery without the latency

With AWS, Cloudsmith takes advantage of what the cloud makes possible: elastic compute, global reach, and the ability to serve large enterprise customers without the operational overhead of managing infrastructure.

The edge is where that global reach becomes tangible for our customers. These are the AWS services we use to deliver global performance and reliability.

 is the backbone of how we distribute artifacts. With over 600 points of presence worldwide, CloudFront allows us to serve packages from as close to the requester as possible. Whether a developer pulls a dependency from their local machine or an automated build system fetches a container image at 2am, an edge location near them serves the request. That proximity is what makes the performance difference our customers depend on.

 extend that further. Authentication and intelligent routing are not afterthoughts in Cloudsmith; they're core to how the platform works. Cloudsmith needs to authenticate and correctly route every incoming request before serving the artifact. CloudFront edge functions enable that logic to run at the edge itself, not at a central registry on the other side of the world. The processing happens where the request is. The result is that every millisecond we would otherwise spend routing back to origin is recovered at the edge, and across the volume of requests we handle – tens of millions per day – those milliseconds add up to faster and more reliable builds for customers.

protects the perimeter of the Cloudsmith platform. While the software supply chain is a high-value target for malicious actors, WAF allows us to block common web exploits and automated bots before they ever reach our API. By leveraging AWS Managed Rules, we ensure our defenses are updated in real-time against emerging threats. This allows us to maintain a high-availability environment where the platform remains performant and accessible only to legitimate users, ensuring the infrastructure behind your artifacts is as secure as the artifacts themselves.

Together, these three AWS services give Cloudsmith the global reach, edge processing capability, and security posture to serve enterprise customers at scale – reliably, and with the performance they need.

AWS EDGE Innovation Spotlight: Cloudsmith | Amazon Web Services

Catch the full conversation: VP of Engineering Ronan O'Dulaing sat down with AWS to discuss how Cloudsmith uses AWS to power its cloud-native artifact management platform. 

A specialized control plane vs. basic registries

Cloud providers offer their own basic artifact registries, but they focus on identity and access management rather than comprehensive supply chain governance.

Cloudsmith provides a unified control plane that goes beyond simple storage. Unlike basic registries or package managers embedded in developer platforms, Cloudsmith delivers:

: We support 30+ package formats, including AI/ML models, in a single repository.

: Using our policy management capabilities (built on OPA), organizations define precise compliance rules. You decide what artifacts are untrusted or non-compliant and block them before they ever enter your environment.

: We don't just scan your artifacts. We continuously enrich packages with new vulnerability and malware intelligence data, ensuring your software supply chain remains protected as new threats emerge.

AI has changed the requirements for artifact management. ML models are significantly larger than traditional software packages, often reaching multi-gigabyte sizes.

Our AWS-backed architecture allows us to adapt. We parallelize metadata fetching and artifact pulls to ensure reliable delivery of massive models. Because we leverage AWS's global reach, these large files still benefit from the same low-latency edge delivery as a standard Python package.

Delivering revenue-critical software with confidence

Reliability and performance are the baseline expectations for modern software delivery. By building a genuinely cloud-native platform on AWS, Cloudsmith ensures that your delivery pipelines are predictable, resilient, and secure.

You don't have to manage clusters, configure regions, or worry about manual replication. You simply get a fast, governed, and reliable software supply chain–globally, and at scale.

See how Cloudsmith handles your specific tech stack. 

How Cloudsmith builds on AWS to deliver enterprise-level speed and uptime

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.

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 

. 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 Blog