Following the recent npm ecosystem attacks, a new threat emerged: the ‘s1ngularity’ attack, and its subsequent evolution into the ‘Shai-Hulud’ worm. The new attack vector demonstrates a significant escalation in the tactics of malicious actors, moving beyond simple package compromise to target the developer’s environment and even their AI tools.

How did this differ from the previous npm supply chain attack?

Both the intention and vector of the attack were different.

The ‘s1ngularity’/nx attack was focused on harvesting credentials and data exfiltration.

The initial entry point was not a phishing attack (which was the vector of the previous attack), instead it exploited a vulnerable GitHub Action, which allowed attackers to steal an npm publishing token.

Notably this was one of the first documented cases of malware using AI command-line tools (like Claude, Gemini, and Q) to assist in identifying and exfiltrating sensitive data.

 as with previous attacks, immediately block any known malicious packages and versions.

 Use your Cloudsmith client logs to identify any user or service account that may have pulled down a malicious package.

 Enable Enterprise Policy Management (EPM) and Continuous Security. Use policies to automatically quarantine packages that are identified malicious by security feeds like OSV.dev.

 Due to the nature of these attacks, it is critical to immediately revoke and rotate all potentially compromised credentials. Think about implementing ephemeral tokens (using OIDC) or strict policies for short-lived tokens.

: implement a more robust security posture. This includes enforcing multifactor authentication, limiting the scope of access tokens, and closely monitoring your CI/CD pipelines for anomalous behaviour.

As with the previous attack, once identified, a simple EPM policy would quarantine malicious packages:

The 's1ngularity' and 'Shai-Hulud' attacks demonstrate that attackers will continue to exploit the trust within the open-source ecosystem. The gap between a zero-day and an n-day is shrinking, and the ability of a threat to self-propagate can cause widespread damage in a matter of hours.

Strengthening your software supply chain starts with understanding where you are today. Our free maturity assessment highlights gaps, benchmarks your current practices, and points you toward practical next steps. 

Npm ecosystem update: a new attack vector emerged with ‘s1ngularity’ and ‘shai-hulud’ attacks

 is right around the corner, and there are 11 clear new Python Enhancement Proposals (PEPs) added to the Python project! There are several over significant changes listed within the 

Python 3.14 brings a whole bunch of useful build improvements, including discontinuation of PGP signatures in 

. Python versions 3.14 and onwards will no longer provide PGP signatures for release artifacts. Instead, Sigstore is recommended for verifiers. Similarly, free-threaded mode (

), which was introduced in the previous version, 3.13, has undergone major enhancements. The implementations outlined in this enhancement are now complete, incorporating updates to the C API, and the interpreter’s earlier temporary fixes have been replaced with long-term solutions.

The Cloudsmith team is really excited about this release and everything that comes with it! Note that some of the statuses may change between the time of this blog being posted and the final release date. Knowing that, let’s jump into all of the new features and improvements in Python 3.14.

Here are a few of the changes that Cloudsmith employees are most excited about in this release:

PEP 761: Discontinuation of PGP signatures

“From my perspective at Cloudsmith, the move away from PGP signatures in Python is a welcome change. PGP has long struggled with usability and the burden of managing long-lived private keys, and while it was the default for artifact signing, it never felt ideal. Sigstore offers a much more practical approach, using short-lived keys tied to human-readable identities, and it’s already gaining traction across ecosystems like PyPI, NPM, Homebrew, and GitHub. We’re also seeing projects we work with, like 

, embracing Sigstore, which reinforces that this shift is a real step forward for security and usability.”

PEP 734: Multiple interpreters in the stdlib

“This was an inevitable development, in my opinion. While the CPython runtime has supported running multiple interpreters, which are independent copies of Python within the same process, for well over 20 years at this point, the feature was still limited to the C-API and thus saw little adoption due to low awareness and the absence of a standard library module. With Python 3.14 introducing the new 

 module, this long-standing capability is finally becoming more accessible, marking a significant step toward mainstream usage. While current limitations remain, their impact will diminish as CPython evolves and the community contributes solutions via 

PEP 784: Adding Zstandard to the standard library

“Python 3.14’s addition of Zstandard (via 

) is an exciting upgrade because it brings one of the fastest, most efficient modern compression algorithms directly into the standard library, alongside a new unified 

, consistently outperforms older formats like 

 by offering both higher compression ratios and dramatically faster decompression speeds, which has made it the de facto standard across filesystems, packaging tools, and industry at large.

By including it natively, Python eliminates the confusion of multiple third-party bindings, enables direct support in core modules like 

, and opens the door for faster, smaller Python wheels and other packaging improvements. The reserved 

 namespace not only avoids naming conflicts with PyPI packages but also creates a clean, future-proof home for compression libraries, much like 

 does for hashing. This change reflects Python’s “batteries included” philosophy while giving developers a state-of-the-art compression tool that is both practical today and well-positioned for long-term usage.”

Free-threaded Python is now officially supported

 this enhancement proposal, which actually sets requirements for advancing 

, which was the larger, ongoing effort to make Python’s 

) optional. PEP 703 outlines a three-phase plan:

First phase introduces an experimental GIL-free build in Python 3.13

Phase two makes this build officially supported - though still optional

While Phase 3 makes it the default. 
This new feature defines the expectations for the second phase, ensuring the free-threaded build is stable, usable, and performant enough for broader adoption.

The motivation behind this shift is to balance the benefits of free-threaded Python, which offers greater concurrency, reduced latency, and expanded threading capabilities against costs such as performance penalties, memory overhead, and ecosystem complexity. Current benchmarks show around a 10% slowdown and 15-20% more memory use compared to the traditional GIL build, both considered acceptable trade-offs for Phase 2.

The APIs introduced so far have proven stable, and further refinements are expected without breaking changes. With growing third-party support and clear criteria for performance, memory use, documentation, and API stability, Python 3.14 is targeted as the point where free-threaded Python becomes an officially supported build.

Standard Library Support for Isolated Python Interpreters

Python 3.14 sees the addition of a new standard library module, 

, to expose CPython’s long-standing support for multiple interpreters in a single process. Each interpreter is strictly isolated, with its own modules, classes, and variables, while sharing only certain immutable or low-level process state. Unlike threads, which share most of the same runtime state, interpreters provide stronger isolation, making them better suited for parallelism, especially now that 

The new module will provide a high-level interface for creating, inspecting, and executing code in interpreters, as well as managing communication through a built-in, cross-interpreter-safe 

. This brings powerful functionality, previously limited to the C API, into Python code. An additional 

concurrent.futures.InterpreterPoolExecutor

 will be provided to simplify concurrent workloads.

The interpreters module defines an Interpreter object with methods like 

 to initialise globals. Interpreters can safely exchange data using 

, which supports pickle-based transfers and special handling for buffer objects like 

. This queue acts as a synchronisation and communication mechanism, enabling patterns like worker coordination across interpreters. For example, the below snippet taken from the PEP documentation shows multiple interpreters sharing a 

 of large data, synchronised with a queue token:

Making Parentheses Optional in Except and Except Blocks

 blocks in Python, users can now catch multiple exception types, so long as the “

” operator clause is not used. Currently, parentheses are mandatory around multiple exception types, a requirement carried over from Python2.

Removing this requirement simplifies the syntax, improves readability, and makes it more consistent with other comma-separated constructs in Python, such as function arguments and tuple literals. Parentheses will still be required when using as to capture the exception instance to avoid ambiguity. The change is purely syntactic, fully backwards compatible, and does not alter exception handling semantics.

Deferred Evaluation Of Annotations Using Descriptors

Python annotations let developers attach type information and metadata to functions, classes, and modules. Traditionally, annotations were evaluated eagerly when the object was defined, which led to common problems with forward references and circular dependencies. 

 attempted to fix this by “stringizing” annotations (storing them as strings), solving the forward-reference issue but breaking runtime use cases where actual objects were expected instead of strings.

A new proposal introduces a third, more flexible approach: lazily evaluating annotations through a dedicated 

 method. At compile time, Python generates a helper function that constructs the annotation dictionary, then attaches it to the object as 

. Accessing these annotations triggers this function, evaluates the annotations only when needed, and caches the results. This design eliminates circular-reference issues, preserves runtime usability, and allows for new introspection capabilities. Furthermore, 

 gain a new format parameter, letting users choose between evaluated values, forward-reference proxies, or source-code strings for annotations.

Here’s a simplified illustration of how this lazy evaluation model works:

With this change, annotations retain their runtime meaning while still avoiding forward-reference pitfalls, which supersedes the enhancement #563 string-based approach mentioned earlier, as well as offering a unified solution for both static and runtime use cases.

Safe external debugger interface for CPython

This introduction of a zero-overhead debugging interface for CPython should allow debuggers and profilers to safely attach to running Python processes. By providing well-defined safe execution points within the interpreter’s evaluation loop, external tools can request code execution without modifying normal execution or introducing runtime overhead.

This mechanism enables scenarios like attaching pdb to live processes by PID, similar to 

, allowing developers to inspect, evaluate, and step through running Python code interactively without stopping or restarting applications. Current approaches to live debugging in Python are risky because they rely on unsafe code injection, which can execute at arbitrary points in the interpreter, leading to crashes, memory corruption, or deadlocks. By integrating a small support structure into each thread state and extending the debug offsets table, this proposal ensures that debugging code is executed only when the interpreter is in a consistent and safe state.

The interface works by having debuggers write control information, such as the path to a Python script, into dedicated memory locations in the target process. The interpreter checks for pending debugger requests at existing safe points (via the 

), executing the provided code without interrupting critical operations like memory allocation or garbage collection.

 API simplifies remote execution for external tools, while environment variables and build flags allow redistributors and administrators to disable the feature if desired. Multi-threaded considerations are handled naturally: injected code runs under the normal GIL, ensuring thread safety, and can target individual threads or all threads as needed. This approach aligns Python with other major languages in live debugging capability while maintaining safety and zero runtime overhead during normal execution.

Deprecating PGP signatures for CPython artifacts

Again, this PEP isn’t merely a deprecation announcement. Instead, we see the introduction of an entirely new security model through Sigstore. Since 

, CPython artifacts have been signed with both PGP and Sigstore. PGP relies on long-lived private keys, which release managers must maintain and protect for many years, creating ongoing risks and burdens. In contrast, Sigstore uses short-lived keys tied to human-readable identities via OpenID Connect, greatly simplifying the signing process while providing stronger ergonomics. Sigstore is already gaining wide adoption across ecosystems like PyPI, NPM, Homebrew, and GitHub.

This new feature will not only deprecate, but will eventually discontinue the PGP signatures for CPython altogether, transitioning fully to Sigstore. Current stable releases (3.11 through 3.13) will continue offering PGP signatures until end-of-life, but new release managers (starting with Python 3.14) will not be required to generate them. Maintaining dual systems has slowed adoption of newer methods, creating a “

” that discourages verifiers from moving forward.

By dropping PGP, CPython can encourage downstream ecosystems to fully adopt Sigstore, while still providing flexibility for extraordinary delays if needed. Though this change shifts reliance to Sigstore’s centralised infrastructure, it aligns with the security practices already expected of release managers and leverages services better suited for long-term key management. Documentation will guide integrators, such as Linux distros and package managers, on verifying artifacts with Sigstore.

Disallow return/break/continue that exit a finally block

Python 3.14 – What you need to know 

Speed, reliability, and security are now essential in modern software delivery. With organizations increasing the speed of their engineering processes, software artifacts, including Docker images and npm packages, have grown to be the foundation of the development lifecycle. It is crucial to manage these artifacts effectively in order to enable teams to deliver to users faster and with greater confidence.

Historically, artifact management, like many parts of the CI/CD pipeline, was managed in-house, with organizations setting up their own artifact repository and infrastructure. Although such a strategy was viable at smaller scales, it frequently resulted in issues, particularly the lack of storage capacity, bottlenecks in performance within a region, and a high maintenance overhead.

In recent years, organizations have been shifting 

 towards the cloud. This move to cloud-native infrastructure removes the physical limits of on-prem systems and allows teams to scale across the world, reduce latency, and sustain high performance on each stage of the CI/CD pipeline.

This blog will discuss seven aspects of how a 

 system can enhance your software delivery processes by scaling and enhancing their performance, enabling teams to deliver software more quickly, dependably, and globally.

1. Elastic scaling of storage and distribution

Conventional artifact repositories often run into difficulties when engineering teams scale their usage. As developers begin generating hundreds of thousands of versions of Docker images, packages, or libraries, traditional on-premise systems require manual maintenance. This often involves increasing on-premise systems, more hardware, manual configuration, and frequent maintenance.

In contrast, cloud-native artifact management leverages elastic scaling to automatically expand storage as demand grows. This guarantees that as engineers produce more artifacts; performance will remain constant. With physical infrastructure deletion, scalability with artifacts is easily accomplished without capacity bottlenecks, and doing incremental upgrading is costly.

 performance does not only hinge on the storage of artifacts, it also depends on how quickly they can be accessed in different regions of the world to support globally distributed teams. The problem of latency is a significant problem in globally spread enterprises when teams are compelled to draw artifacts in one, centralized on-premise repository, which is often very distant from where builds are occurring. It may cause slow builds, delays in deployments, and exasperated developers.

Cloud-native artifact management systems address this issue through replication and caching. Replication is the process of storing copies of the artifacts in more than one location, in places near the teams that require them. Caching goes a step further: When an artifact is initially requested, it is momentarily stored, or rather cached, in edge servers at key points around the world. The next time a team in that region orders the same artifact, it can be delivered directly out of the cache, and they do not have to take a long, latency-intensive journey back to a central repository.

Systems and developers can retrieve the closest copy of an artifact, which can significantly reduce their retrieval time. This type of cloud-native scaling makes global distribution a strength and not a weakness, meaning that the performance of artifacts will not be weakened when teams are operating in North America, Europe, or Asia.

3. Seamless integration with CI/CD pipelines

Automation is the core of the new-generation software delivery, and artifacts are the key to any build, test, and release. Using cloud-native artifact management, repositories have been built into CI/CD pipelines, and artifacts have been made a first-class citizen in the delivery process.

New builds are automatically checked, analyzed and subsequently validated. Integration with other tools (i.e., Jenkins, GitHub Actions, and GitLab CI) through webhooks and APIs allows pipelines to continue running seamlessly. Such integration enhances the DevOps artifact management that helps in delivering much faster with a lesser amount of manual work and risk.

 repositories are often offline due to maintenance, upgrades, or other unexpected loss of online accessibility, thereby making development difficult. Cloud-native systems provide reliability by design, with redundancy and auto-healing load balancing being part of the infrastructure. This guarantees the presence of artifacts even when the demand is high.

For engineering teams, that means repeatability, uninterrupted workflows, and confidence that outages won’t disrupt delivery. By removing the fear of downtime, organizations can stay on schedule and ensure developers always have the artifacts they need.

Scaling artifacts with traditional infrastructure is typically expensive in terms of procurement costs, such as servers, storage, and licenses. Cloud-native models typically remove this limitation by allowing users to paying-as-you-go, aligning cost directly with their use.

Enhanced capabilities, such as deduplication, avoiding storage redundancy, and tiered storage, aim to keep commonly used artifacts from high-performance systems and archive older versions in lower-cost ones. This is an efficient way to enable scale as well as prevent overspending because of team growth. When artifact scalability and economic efficiency combine, so do performance and cost in cloud-native platforms.

The larger your store of digital artifacts becomes, the more critical it is to ensure their integrity and compliance. Cloud-native repositories often have built-in security controls, as they help to keep them trustworthy and auditable. Immutability characteristics disallow alterations from being made to published artifacts, and access restrictions stop undesired users from publishing or retrieving artifacts. 

Artifacts are encrypted both at rest and in transit and are integrated with SBOM reporting to achieve regulatory (SOX, HIPAA, GDPR) compliance. This is a security-first approach that guarantees both speed and trust to enterprises, as artifact performance is coupled with integrity and compliance.

7. Future-proof scalability for innovation

Technology does not stand still, and neither should your artifact management strategy. Cloud-native systems are futuristic and therefore can be scaled as organizations start adopting new architectures like microservices, edge computing and AI-driven development.

An OCI-aligned open standard helps an enterprise achieve long-term tool- and platform-portability. Such flexibility denotes that cloud-native scalability can be used to accommodate new workloads and worldwide growth without subjecting teams to re-engineering artifact handling. Organizations prepared today receive a platform that keeps in step with tomorrow’s innovation.

How Cloudsmith delivers cloud-native scalability and performance

Cloudsmith has been created to address these problems through its fully managed and cloud-based 

. Our platform is elastic, globally distributed, and tightly integrated with CI/CD pipelines without the complexity of managing infrastructure yourself.

 Allow storage and bandwidth to scale automatically as your volumes of artifacts expand.

 Deploy artifacts to 225+ edge sites around the world to be close to immediate access.

 Be able to plug directly into pipelines to securely store, scan, and deploy artifacts.

 Artifacts are available all the time, and 99.99 percent uptime makes this possible with redundancy.

 Immutability, RBAC, encryption, and SBOM capabilities keep your supply chain compliant.

 with global reach, performance, and security, Cloudsmith transforms artifact management from a bottleneck into a competitive advantage.

As the volume and complexity of software artifacts grow, organizations must ensure both speed and scalability in how they manage them. With cloud-native artifact management, businesses unlock global distribution, resilient infrastructure, and built-in performance optimization.

With cloud-native scalability of artifact storage, your teams will have faster innovation, more reliable shipping, and the trust of your customers—today and beyond.

1. What kind of software artifacts are best suited to use cloud-native storage?

Containers, language packages (Python, npm, and Java), Helm charts, and operating system packages can all be scaled in a cloud-native environment.

2. How does artifact performance differ between cloud-native and on-prem repositories?

Cloud-native utilizes multi-region replicating, distributed caching, and scalable infrastructures in order to minimize the latency and accelerate the speed of retrieval at a global level.

3. Do large enterprises only use cloud-native artifact management?

No, startups, medium-sized teams, and enterprises all enjoy it. Cloud-native is cost-effective at each scale of size because of its pay-as-you-go model.

7 Ways Cloud-Native Improves Artifact Management Scalability and Performance

DevOps is hard enough. You really don’t want your tooling to introduce new bottlenecks. You need speed, security, and reliability from your software supply chain—and when things go wrong, you need a support team that actually delivers.

 was born in the cloud. Legacy vendors built their tools for on-premise deployments, and even when these tools are “managed” in cloud environments, they can feel sluggish, fragmented, and reactive. Vendor support often mirrors that—gated to named users only, slow to respond, tiered behind ticket queues, and disconnected from engineering.

 flips the model on its head - not just in the way the product delivers on artifact management, but in the way it enables our team to deliver on customer support.

Cloud-Native by design means support that moves at your speed

. No patchwork of on-prem tools, no outdated architecture. This matters because it creates some really important support-related outcomes:

 Our cloud-native platform means our support team sees what’s happening across environments in real time. Legacy tools often require layers of logs, configs, and manual back-and-forth.

, without any manual intervention or advance planning. Legacy vendors often leave customers waiting for infrastructure adjustments 

 Cloudsmith evolves daily with continuous delivery. Support is never stuck in “which version are you on?” purgatory. That means when you request support, there’s no confusion about what version you’re on, or whether your feature set is “old” or “incompatible.” We’re all running on the same platform, always.

Cloud-native isn’t just a better way to deliver artifacts. It’s what enables customer support teams to be effective, fast, and relevant.

Support as a strategic partner, not a ticket queue

Here’s where the difference really shows. Legacy providers often treat support as an afterthought: slow response times, hidden behind multiple tiers, and “premium” price tags just to get basic help.

Our support is reactive, of course—we’re here when you need us–but it’s also proactive and embedded into how the platform operates.

 From the first interaction, customers speak with dedicated engineers who understand the platform inside out. There are no scripted handoffs, and no wasted time.

 Because we manage a single global service, our team sees trends across customers. If something looks off in your setup, chances are we’ve already solved it elsewhere—and we’ll help you get ahead of it.

 Support isn’t just about fixing today’s issue. Our team feeds insights back into product and engineering, ensuring your needs directly shape the roadmap.

Contrast that with legacy vendors: tickets may vanish into silos, customers often wait days for an initial response, and when answers finally come, they can feel disconnected from the reality of modern DevOps pipelines.

 is about service, and it’s also about getting a competitive edge. With Cloudsmith you get:

 than legacy players bogged down by old architectures.

 from experts who live and breathe supply chain defense.

—we’re invested in your success, not just your subscription.

In software supply chains, speed and reliability are critical. Powered by AI assistants and using modern tooling, teams are moving faster than ever to build and release software. The last thing they need is an artifact management system that slows them down. You really don’t want to have to be navigating outdated interfaces, piecemeal architectures, and frustrating support experiences that feel more like barriers than help.

We believe that cloud-native infrastructure and dedicated support aren’t just “nice-to-haves”—they’re essential for building trust, security, and long-term success.

With competitors, you are a number. At Cloudsmith, you talk to real people who take your problems seriously.

An enterprise-class platform is only as good as the people behind it. Cloudsmith’s dedicated support team ensures that customers have more than a tool—they have a partner invested in their success.

Cloud-native means better customer support, too

The npm ecosystem was hit yesterday by a malware attack affecting popular packages like 

. Both packages are typically bundled into frontend builds. Once included, the malicious payload executes.

These attacks are becoming more frequent - we reported on a 

similar attack on npm packages just 12 days ago

How you react depends on what is known about the threat:

The issue is real, but not yet reported in public databases

You cannot automatically detect or block it - your only option is rapid manual actions

The issue is documented and tracked (i.e. it has a CVE or MAL ID)

Security feeds and tools, including Cloudsmith’s Enterprise Policy Management (EPM), can use that tracking to automatically quarantine or block affected packages

, it was considered a zero-day threat (potentially compromised packages were identified, but no official designation yet).

Within 24 hours, these packages were confirmed as malicious, and added to the 

. Cloudsmith and other similar platforms can then OSV.dev updates and thereby enable automated remediations.

We recommend the following actions for all Cloudsmith customers, regardless of whether you’ve confirmed that any affected packages have been used in builds or are currently present in any of your Cloudsmith repositories.

For Zero-day threats - Block with Deny Rules

1. Add [Deny Rules] that block downloads immediately. 

This stops any installs in dev, CI, or production environments.

For this scenario, a simple set of rules targeting the compromised packages/versions would have blocked all download attempts. This protects developers who may not have heard the news yet.

See the end of this article for a full list of Deny Rules.

 to identify who pulled compromised packages and when. Cloudsmith logs are near real-time, so searching for and identifying users andservice accounts that have accessed these packages will help determine potential impact.

For N-Day threats - Quarantine and Flag with EPM

. Put policies in place to quarantine malicious packages that do not have a fix, or have not been verified and granted an exception from your security team.

Our OSV.dev feed refreshes every hour and will detect newly identified malicious packages automatically. This protects you if compromised packages are already in Cloudsmith repositories. In order to enable continuous securityadd an 

 to automatically tag and quarantine new malware.

The gap between zero-day and n-day is when development teams are most exposed. This “lag” introduces risk, against which the fastest defense is Deny Rules.

Once advisories are live and the zero-day is now an n-day, EPM and Continuous Security take over, eliminating manual effort and keeping build pipelines safe.

Looking ahead: smarter protection is coming

Cloudsmith includes detection and protection against malware and vulnerabilities as a native capability in our Ultra and Enterprise tiers. Every artifact in a Cloudsmith repository is, by definition, in a controlled, policy-enforced environment.

We’re working to include more threat intel sources, richer context, and community feeds like deps.dev, along with the ability to bring your own internal threat data into Continuous Security.

Create a Deny Rule for each separate query string.

npm ecosystem alert: What you need to do today with Cloudsmith

I learned to code in BASIC on a Commodore 64 in the early 1980s. BASIC was actually a pretty neat high-level abstraction of assembly language, which itself was an abstraction sitting on top of machine code! Since then, I’ve seen a steady stream of higher-level abstractions - relational databases, object-oriented languages, package dependencies, open source libraries, cloud-native development, containers, serverless - that have made software developers more productive, and helped us build ever more powerful applications with them.

AI is the latest abstraction layer that sits on top of existing technology, making the underlying components more powerful and easier to use. A huge amount of R&D and startup capital in the past few years has gone towards exploiting this new abstraction.

The newest and best ideas naturally attract top talent and funding. Companies and startups building cool new AI-powered apps have their choice of tech stack. And many of them are creating their new software development tool chains around Cloudsmith, which is very satisfying to Cloudsmithers.

, who built an AI-powered platform pathologists use to diagnose cancers. They manage binary packages in Cloudsmith that they use to build for a wide variety of target environments. Or 

, who builds industrial computer vision applications that improve quality and productivity, using Cloudsmith to manage binary artifacts that go into their build pipelines. 

 provides a machine learning platform for document processing and automation, built on Cloudsmith for internal development and external distribution of containers and packages. And 

, who have built an AI-powered due diligence platform, using Cloudsmith as their single source of truth for binary artifacts.

Companies that build critical infrastructure for use by other AI companies are also gravitating to Cloudsmith. Take 

, who helps organizations use, manage, and govern AI metadata with their enterprise-grade context platform. They chose Cloudsmith to make sure their artifacts are reliably and securely distributed to enterprise developers. Or 

, who distributes their SDKs and runtimes via Cloudsmith for delivery of AI-driven perception solutions to robotics and computer vision tool companies. Then there’s 

, an open source AI search platform used to develop and run large-scale applications, combining big data, vector search, machine-learned ranking, and real-time inference to enable AI applications like retrieval-augmented generation, recommendation, and intelligent search at enterprise scale. Cloudsmith supports distribution for Vespa, streamlining delivery for their open source community as well as enterprise users.

And then it’s companies who deliver AI directly to the hands of end users. 

 calls itself “the world’s most private AI,” assisting users in real time across a wide range of personal tasks. They use Cloudsmith to build and distribute packages across the software supply chain.

Cloudsmith is best known for our enterprise-grade artifact management platform, which controls and secures the software supply chain for the world’s most demanding Fortune 500 and Global 2000 organizations. But there’s a reason we also show up so often as the platform of choice for innovative AI startups and spinoffs. These companies are typically run by lean teams of seasoned software engineers. They know what they need, and they want to do it right the first time. They want developer-friendly, well-documented tools that just work.

 to manage their Hugging Face models and datasets, and we’re increasingly powering our own development of new features with AI tools. But it’s also notable that the world’s most interesting AI companies are also choosing Cloudsmith - not just to manage ML models, but to power their entire software supply chain. That’s a vote of confidence that makes us proud to be Cloudsmithers.

The platform of choice for AI companies

By submitting this form, you agree to our 

In a world where software ships in seconds, teams are still chained to legacy systems built for a different era. What once passed as “good enough” for storing and distributing builds has become a drain on productivity - adding risk, slowing delivery, and quietly inflating costs year after year.

In this post, we’ll break down the hidden cost of legacy artifact repositories, discuss the importance of modernizing through cloud-native artifact management, and demonstrate how you can leave the old infrastructure that has been slowing your software supply chain.

Cloudsmith Blog

The true cost of legacy artifact management

13 sessions not to miss at KubeCon and CloudNativeCon 2025

AI generated code is changing the demands being put on artifact management

Artifact distribution: Securing the trust with your own domain

Breaking the "Department of No": Ship fast but also secure

Using vulnerability scoring systems to prioritize risks in your environment