By submitting this form, you agree to our 

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

2026 Artifact Management Report

Many engineering teams treat PyPI, npm, Maven Central, and other upstream registries as trustworthy by default. They're not. These registries have no admission controls, no malware guarantees, and no obligation to notify downstream consumers when a vulnerability emerges for a previously clean package. While they offer convenience and availability, teams need to be careful not to conflate ease with safety.

Every time a developer pulls a dependency, they’re making a trust decision. But who vets that trust decision, especially with transitive dependencies? What often happens is the package enters the environment unchecked, moves into the build, gets stored in an artifact repo, and is assumed safe indefinitely. No one explicitly decided to trust it. It just arrived.

This is the structural vulnerability in modern software supply chains and better scanning alone won’t close the gap. The problem isn't just that teams occasionally pull bad packages. It's that teams delegate the decision to trust anything at all to the registry, with no policy enforcement at the moment that actually matters.

The cooldown period: A governance posture, not a product feature

The package cooldown period is one response to this problem gaining traction in DevSecOps.

The concept is straightforward. A newly published package, or a new version of an existing package, doesn't go straight to your development environment. It enters a controlled holding state for a defined period, where it undergoes continuous evaluation against evolving threat intelligence before any build can consume it. Ideally, teams can set the length of that window in customizable policies, calibrated to the risk window for their organization and/or a given ecosystem.

A cooldown is distinct from quarantine, which is an open-ended hold triggered by a specific CVE or malware indicator on a known-bad package. A cooldown period is time-based and preventive. The cooldown policy exists because the highest-risk window for a newly published package is in the first few days, when a compromised or malicious package is most likely to surface and when threat intelligence is still trying to catch up to it.

Enforced intake holds are standard practice in regulated industries, like pharmaceuticals, food manufacturing, and medical devices. You don't distribute what you haven't cleared. The software industry is arriving at the same conclusion, just later, under more duress (thanks to AI), and with considerably more attack surface.

The difference between a cooldown policy and the vague notion of "we'll scan before we use it" is precision. Cooldown policies are written as code. Teams define the threshold, the scope – which package formats, which registries, which versions, etc. – and what happens when a package triggers the policy: hold it, tag it for review, block it with a message. The parameters are custom because the risk tolerance, regulatory context, and build velocity are different for every organization.

The anatomy of a modern supply chain attack

 campaign made the failure mode visible at scale.

Shai-Hulud is a self-replicating worm that spread through compromised npm developer accounts, inserting malicious code into legitimate packages belonging to those developers. The mechanism that Shai-Hulud used is what matters here: it didn't introduce obviously malicious 

 packages. It compromised packages that were previously legitimate, with real publishing histories and real downstream users. Those packages would have passed a point-in-time scan at first pull.

The second wave, detected in November 2025, escalated the technique – executing during the pre-install phase rather than post-install, which moved execution ahead of most pipeline scanning controls. Within hours of detection, the campaign compromised over 700 npm packages, created more than 27,000 malicious GitHub repositories, and exposed approximately 14,000 secrets across 487 organizations.

A cooldown period, combined with continuous re-evaluation against new threat intelligence, changes the exposure window. Not because it catches everything at intake – it doesn't – but because the hold creates a window in which intelligence can catch up. A package that passed on Monday may be flagged by Wednesday. Without a cooldown policy, your build already consumed it on Monday.

 ran the same playbook on a package with an even larger blast radius. Axios is the dominant HTTP client library in the JavaScript ecosystem – present in roughly 

 of cloud and code environments and downloaded approximately 100 million times per week. The attacker compromised the npm account of the project's primary maintainer and published two backdoored versions within a 39-minute window. Both versions introduced a hidden dependency that deployed a cross-platform remote access trojan to macOS, Windows, and Linux, targeting developer secrets, cloud credentials, SSH keys, and CI/CD pipeline tokens. The malicious versions were live for roughly three hours. Due to the short exposure window but high prevalence of axios, even limited availability resulted in measurable execution across environments.

, compromised by a separate threat group in the same period, demonstrated what that blast radius looks like in the AI stack specifically. LiteLLM is a unified proxy layer used to route requests across over 100 LLM providers, like OpenAI, Anthropic, AWS Bedrock, Google Vertex, etc. Compromising LiteLLM didn't just expose a build environment, it could provide attackers with credentials that span an organization's entire AI infrastructure. The attack reached LiteLLM indirectly, through another attack event against Trivy, a security scanner that LiteLLM's CI/CD pipeline trusted. The attacker poisoned that trusted dependency, harvested PyPI publishing credentials through it, and published malicious versions from there.

The vector changes across every one of these campaigns. The tactic – compromise something the ecosystem already trusts and weaponize dependency resolution – does not. The scope, speed, and cross-registry reach of these attacks show the limits of manual review in the Age of AI. When attackers can weaponize 100 million weekly downloads inside a three-hour window, the response requires automation and enforcement at the point of pull.

Cooldown policies and developer experience

Security teams that propose cooldown policies consistently encounter the same pushback: they add delays to developer workflows, create friction in the build process, and slow down teams already under delivery pressure.

These are legitimate concerns from engineering teams, even when they buy into a tighter risk posture. Fortunately, the right tooling provides a real solution.

The goal of a cooldown policy isn't to hard-stop every new dependency. It's to introduce a controlled hold with a clear, automated release path. Done correctly, a cooldown policy is largely invisible to developers working with packages that already cleared policy. The friction targets new packages in their highest-risk window, not on the entirety of the dependency graph on every build. For packages that pass continuously without incident, the cooldown period is a one-time delay on first use.

There's also a practical counterargument that often goes unmade: most engineering teams aren't looking to upgrade packages on zero-day. Unless teams configure a pipeline to pull the latest version automatically – an explicit choice, not a universal default – a developer may not know an update is available for days or weeks after publication. For those teams, a cooldown period introduces no meaningful delay. The package sits in its hold state and when it clears policy it is available when the team is ready to consume it. In this case, the friction becomes largely theoretical.

The objection to cooldown policies becomes harder to sustain when considering the alternative. The delay from a cooldown period is likely hours or days when first pulling a new package. Compare that to the blast radius from a compromised dependency that entered your environment unchecked. Teams measure the impact in incident response hours, remediation scope, and, increasingly, regulatory exposure under compliance frameworks, like DORA, CRA, and SOC 2, that treat supply chain controls as auditable requirements, not optional best practices.

The friction argument also assumes that the 

 alternative is speed. It isn't. Uncertainty is a significant factor as well. A supply chain where teams can answer the "are we affected?" question when a CVE drops because they tracked everything on entry mitigates the uncertainty factor drastically.

Building a mature supply chain governance posture

Cooldown policies are one layer in an enforcement stack, not a standalone fix. A mature posture has four components:

 Evaluate every package against policy before it reaches the developer – not after the build, not in a separate scanning tool downstream, but at the moment the request occurs. This is where cooldown and quarantine policies activate.

Today’s threat intelligence is different from that of last week so packages need on-going re-evaluation to stay up-to-date. CVEs don't announce themselves in advance. Malware indicators evolve. The assumption that a package is safe because it passed once is precisely the assumption that Shai-Hulud exploited.

 Context matters. Block with a message. Hold with a tag. Allow with a warning. Developers need clear, actionable answers – not a silent failure that sends them looking for a workaround that bypasses your controls entirely.

Unified visibility across formats and registries:

 "Are we affected?" needs a fast, authoritative answer. That's only possible if there's a single source of truth for what's in the environment and what state it's in based on policy.

Making cooldown policies operationally viable at scale

The conceptual case for cooldown periods isn't difficult to make to a CISO. The operational challenge is implementing them in a way that doesn't break builds, generate alert fatigue, or require a dedicated team to manage exceptions.

This is where the underlying platform matters. Cloudsmith prioritizes enforcement. It evaluates packages against your policies at the point of first pull, before it reaches the environment or developer. Cooldown policies, quarantine actions, and blocking responses are configurable and written as code, giving security teams precise control over parameters without creating blanket friction for engineering.

The critical piece is what happens after intake: continuous re-evaluation. A cooldown period without ongoing re-evaluation is still a point-in-time scan – just one with a delay attached. Cloudsmith’s vulnerability data sources update multiple times per hour. The platform uses a lightweight matching process to associate new vulnerability data with existing packages in your registry continuously. When the threat landscape changes for one of your packages, this triggers your policies to run and take action on the impacted package(s). That combination – policy enforcement at intake plus continuous monitoring after the fact – is what narrows the exposure window.

For organizations with DORA, CRA, or SOC 2 obligations, this also produces the audit trail that auditors will ask for: a traceable record of what entered the environment, when, under what policy conditions, and whether it is still safe.

The gate doesn't protect you if it only checks once. Supply chain governance is not a point-in-time moment – it's a discipline. Cooldown periods are one piece of that discipline: a concrete, policy-driven practice that treats trust as something that has to be earned constantly, not assumed at the point of first pull.

Want to talk through what supply chain governance looks like for your organization?

 Whether you're building the case internally or evaluating tooling, we're happy to help you tackle the problem. 

Jason Myers

Technical Content Marketer

Your upstream registry is not your friend: Why security teams are demanding package cooldown policies

On April 30, 2026, the Mini Shai-Hulud campaign moved beyond npm and into Packagist. Attackers replaced the contents of 

, Intercom's official PHP client, with over 20.7 million lifetime installs, with a credential-stealing payload that executed at install time, before any application code ever called the library. PHP teams, Laravel applications, and continuous integration (CI) pipelines that updated to that version may need to treat affected environments as compromised.

The attack exploited two properties of Packagist that most PHP developers have little reason to question.

Packagist versions are not immutable. The registry mirrors tags from upstream Git repositories, and those tags allow force-updates to point to a different commit. The attacker force-pushed a malicious commit behind the existing 

 tag, replacing a known-good release without changing its version number. Any developer or CI system that ran 

 after 20:53 UTC on April 30 received the compromised artifact, even with an explicit version pin.

 as a Composer plugin, subscribing it to the 

 hooks. Composer ran attacker-controlled code as a natural part of installation so it didn’t require an import. The plugin executed a shell script that downloaded Bun 1.3.13 from GitHub Releases and ran an 11.7 MB obfuscated JavaScript payload called 

 as a background daemon. A legitimate PHP SDK has no business doing any of that.

 harvests credentials broadly: GitHub CLI tokens, npm tokens, SSH private keys, cloud credentials across AWS, Azure, and Google Cloud Platform (GCP), Docker registry credentials, Kubernetes configuration, HashiCorp Vault tokens, and 

 files. It also queries cloud secret-management services directly, e.g., AWS Secrets Manager, Azure Key Vault, GCP Secret Manager, and Kubernetes Secrets.

The payload encrypts stolen data with AES-256-GCM before exfiltrating it to a hardcoded endpoint at 

. If that channel fails, it falls back to GitHub-based exfiltration using any GitHub credentials it has already harvested.

It also carries supply chain propagation logic. Stolen npm tokens let it republish modified packages with injected install-time scripts. It writes payload files into GitHub repositories using commit messages like 

, designed to disappear into normal developer workflows.

The Mini Shai-Hulud Packagist attack follows the same pattern as the 

: a trusted package, a payload injected silently at install time, and a detection window too narrow for teams pulling directly from public registries to rely on.

Cloudsmith sits between your teams and public registries, applying security controls before packages reach build environments or developer machines. Age-based (

) policies would have identified the compromised 

 artifact immediately on publication, blocking it from entering any build until it cleared a configured minimum age threshold. According to internal data, in 2025, 99% of malicious npm packages received official verification within 72 hours. A cooldown policy buys exactly that kind of margin.

Cloudsmith continuously ingests threat intelligence from OSV.dev and the OpenSSF Malicious Packages project. Continuous package enrichment matches cached packages to malicious identifiers. A positive match triggers security policies, which automatically take the prescribed action that users define, e.g., block, quarantine, tag, etc., without requiring manual triage. Routing all Composer requests through Cloudsmith as an upstream proxy also gives your team a full audit trail of which package versions entered your artifact store and when. These are the first questions you need to answer when scoping an incident like this.

If you want to understand how these controls apply to your current Packagist and Composer setup, 

Nigel Douglas

Head of Developer Relations

Mini Shai-Hulud reaches Packagist: the intercom/intercom-php compromise explained

Software delivery is often the last, yet frequently neglected, mile of the development lifecycle. For independent software vendors (ISVs), SDK providers, and teams shipping internal tools, the “how” of distribution is just as critical as the “what.” Too often, teams find themselves building and maintaining custom download pages, hosting infrastructure, and complex access controls that add zero value to their core product. These DIY systems are expensive to run, difficult to scale globally, and notoriously easy to misconfigure from a security standpoint.

When software downloads live on generic, third-party domains or lack clear, professional access controls, you risk losing the very thing your product depends on: developer trust. Distribution is an early trust checkpoint for many developers. If a developer hesitates to adopt your software because the delivery method feels disconnected or insecure, you’ve hit a roadblock that slows down your entire adoption funnel.

Software distribution should meet basic expectations for security, access control, and traceability without requiring you to become an infrastructure company. 

Cloudsmith Broadcasts

Broadcasts is Cloudsmith’s built-in, dedicated software distribution capability designed for delivering packages to customers and partners. It allows your team to publish software through secure, branded endpoints hosted under your own domain. Essentially, it acts as a professional front door for your artifacts, abstracting away the headache of building or maintaining custom download portals.

Built on Cloudsmith’s cloud-native architecture, Broadcasts handles the heavy lifting of global scaling and replication. Whether you are distributing a public CLI tool to thousands of developers or a proprietary SDK to a handful of enterprise partners, Broadcasts ensures your software delivery is available, secure, and on brand. It supports both open-source and commercial distribution, and manages access through granular entitlements and seamless integration with native developer tools.

Professional delivery with your own branding

Your brand shouldn’t stop at your documentation page. Many teams struggle with package endpoints that feel disconnected from their identity, leading to confusion and reduced trust among the developer community. Broadcasts solve this by enabling teams to present their distribution experience with their own identity, featuring the same branding, domain, and look and feel that users expect.

By using custom domains and tailored presentation settings, you provide extra reassurance. When a user decides whether to install a package, seeing your company’s domain and branding reinforces that the software is authentic and supported.

Beyond aesthetics, Broadcasts give you control over the technical presentation of your packages. You can configure how to display package information, download links, and license details to end-users. This flexibility ensures that you are providing the exact context a developer needs to successfully integrate your software, all without compromising Cloudsmith’s built-in security and reliability.

Not all software is meant for everyone. Whether you are protecting commercial IP or managing internal tools, Broadcasts provide a range of access models to fit your distribution strategy.

For community tools or public-facing software, public Broadcasts make all packages from a repository openly accessible. This is ideal for increasing the reach of your software without forcing users through unnecessary authentication hurdles.

Protecting proprietary content–like premium SDKs or internal artifacts–is a major challenge for many organizations. Setting up secure, access-controlled methods often requires significant engineering time.

Private Broadcasts provide a dedicated, access-controlled portal where you manage access through secure entitlement tokens. This ensures that only authorized partners or internal teams can view and download your packages. It guarantees robust security, compliance, and IP protection without compromising the end-user experience. You get the security of a private repository with the professional interface of a public one.

The best distribution platform is the one developers don’t have to think about. Developers expect to fetch packages through native tools, whether it’s npm, pip, maven, or a system-level CLI. If your distribution method doesn’t align with these workflows, you create friction that slows down adoption.

Broadcasts are built to integrate directly with native developer tooling. Users can access artifacts through their preferred CLI or CI/CD tools, creating a smooth, workflow-friendly experience. By meeting developers where they already work, you remove the roadblocks that can stall the rollout of new software versions.

Distributing software shouldn’t be a black box. Many teams ship artifacts without knowing which versions users actually download, who is using them, or whether adoption is trending up or down.

Broadcasts include built-in analytics that provide clear visibility into software distribution and adoption. You can track:

: Understand the raw volume of software consumption.

: See which versions are popular and which are being phased out.

: Identify where in the world your users are located.

: Monitor trends over time to predict infrastructure needs or marketing success.

These insights help teams optimize their delivery strategies and understand user behavior more deeply. This data is accessible through both the Cloudsmith web app and the API, allowing you to feed these metrics into your own internal business intelligence tools.

One of the primary differentiators of Broadcasts is its ease of use compared to DIY alternatives. You don’t need to spend weeks designing a portal or configuring web servers.

You can enable a Broadcast instantly from any existing Cloudsmith repository. This immediately creates a professional interface for your end-users without the need for additional infrastructure.

Upload your logo, set your brand colors, and configure your custom domain.

: Navigate to your repository and enable the Broadcast feature.

: Choose between public or private access and generate entitlement tokens for your users if necessary.

: Monitor your performance through the built-in analytics dashboard.

For more information about specific settings, check out the 

The goal of Cloudsmith Broadcasts is to remove the burden of distribution infrastructure. By reducing operational overhead and security risks, Broadcasts help your team stay focused on what matters most: building your core product.

By aligning distribution with your brand identity and providing the tools for secure, manageable access, you can deliver a professional experience that reinforces trust and accelerates adoption. Stop building custom portals and start broadcasting your software with Cloudsmith.

 to discuss your unique distribution needs.

Cloudsmith Broadcasts: Distribute software on your own terms

In a modern development environment, performance and security are inextricably linked. Our 

 reveals that software development in the age of AI is sitting on a fragile foundation of complex infrastructure and institutional inertia.

As teams become more distributed and the volume of artifacts, from standard containers to multi-gigabyte AI models, continues to grow, the “performance gap” between central hubs and remote regions is becoming a critical failure point for the global enterprise.

Maintaining artifact management systems isn't just a background task; for many, it’s a significant drain on high-value engineering resources. When your infrastructure is a legacy, self-hosted system, scaling is rarely a “set it and forget it” operation.

Our data shows that on-prem solutions remain common in otherwise cloud-centric industries. A significant portion of the industry remains stuck in a cycle of reactive maintenance – patching, upgrading, and manually provisioning storage just to keep pipelines moving.

 are now losing more than 20 hours every month to basic registry upkeep. This is time that could be spent on strategic product initiatives, rather than managing the plumbing of the software supply chain. When your infrastructure requires manual intervention to survive a release cycle, your operational overhead stifles your deployment speed.

For global organizations, the distance between a developer and their artifact registry translates directly into lost productivity. Legacy systems designed for a single data center struggle to provide parity for engineers in remote regions, leading to a two-tier developer experience.

A slow download or a registry timeout isn't just an annoyance; it's a blocker that causes CI/CD pipelines to fail. For teams distributed across continents, the performance problems at the edge result in inconsistent build times and frequent disruptions. Our report explores the depth of this performance imbalance and why centralizing your infrastructure in a single data center is no longer a viable strategy for the global stage.

Cloudsmith was built to solve the performance limitations of localized registries. By utilizing a genuinely cloud-native architecture, we move your artifacts closer to the people and machines that need them, regardless of where they are in the world.

 The user should not be concerned with provisioning storage or compute. Cloudsmith scales automatically with your usage, whether you are pushing a small patch or a massive AI model.

 By utilizing a dedicated Package Delivery Network (PDN), Cloudsmith ensures that a developer in Tokyo gets the same sub-second fetch speeds as a developer in London.

 Cloudsmith offloads your operational burden, ensuring that builds and releases remain available even during usage spikes or third-party outages.

As organizations start to deal with the increasing demands placed on development pipelines by AI, they require managed, high-performance solutions to keep up. Our data shows that 

 are already planning to migrate to managed cloud solutions in the next 12 months, while 

 want to migrate but are currently blocked..

Consolidating your infrastructure into a single, cloud-native source of truth isn’t just about speed; it’s about ensuring your delivery pipeline is resilient enough to handle the massive scale of AI-related development.

This post highlights just one part of the performance challenges facing modern DevOps teams. For a deep dive into regional latency issues, the impact of outages on release cycles, and more data on the true cost of legacy tech debt, 

Performance matters: How infrastructure impacts CI/CD

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.

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.

Cloudsmith Blog

Your upstream registry is not your friend: Why security teams are demanding package cooldown policies

Mini Shai-Hulud reaches Packagist: the intercom/intercom-php compromise explained

Cloudsmith Broadcasts: Distribute software on your own terms

Performance matters: How infrastructure impacts CI/CD

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

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

How Cloudsmith can protect against the LiteLLM attack

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

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