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.

Legacy artifact management involves older on-premise artifact repositories or in-house custom systems. These tools were designed in another era, when teams used monolithic applications and updates were done once a year or even less.

The modern reality is very different. Cloud-native development, continuous CI/CD pipelines, and distributed engineering teams need a modern artifact management approach that delivers scalability, uptime, and built-in security.

This is where legacy artifact repositories fall behind. Many teams assume that on-prem systems are “more secure” because they’re isolated, but isolation no longer protects against today’s threats. Most attacks now originate upstream, through open-source dependencies that already contain vulnerabilities, malicious code injections, or compromised packages. 

With the volume and speed of issues emerging in the open-source ecosystem, an isolated, self-hosted repository cannot keep pace without continuous scanning, real-time visibility, and automated updates. Without these protections, legacy artifact management becomes a blind spot in the software supply chain - quietly storing and distributing unverified or unsafe artifacts.

The hidden costs of legacy or on-premise artifact repositories

Legacy systems can feel safer to stick with - they’re already in place and “working.” But maintaining the status quo often hides bigger costs: outdated infrastructure, ongoing maintenance, and mounting security risks from unpatched or unsupported components.

Legacy repositories need to be manually patched, updated, backed up, and scaled. Teams spend valuable engineering time on server management instead of innovation. Each new project or environment increases the complexity of configuration and slows down the development.

Hosting artifact repositories either in on-prem or in self-managed cloud VMs requires continued expenditure on storage, bandwidth, and compute. The costs increase unintentionally as the size and volume of artifacts grows (especially large Docker images or build artifacts). Beyond infrastructure, many older systems also require costly vendor support contracts for upgrades, patches, and troubleshooting. These fees often increase over time and are non-negotiable.

Legacy systems often lack built-in scanning, access control, or software bill of materials (SBOM) capabilities. Lacking transparency in dependencies leaves teams exposed to vulnerabilities and unmet compliance requirements - something that enterprises will not be able to afford in 2025 and beyond's regulatory environment.

As repositories grow, performance bottlenecks emerge - developers face slower downloads, failed builds, and pipeline downtime, all of which directly slow release velocity and drain productivity.

Why cloud-native artifact management is a change worth making

Legacy tools may have provided the groundwork for early DevOps, but they cannot keep up with the current software landscape. Modern organizations need next-generation artifact management - cloud-native solutions designed for speed, security, scalability, and seamless integration with cloud-native CI/CD pipelines.

 platform is more than just a storage location for packages - it’s a critical pillar of your software supply chain security. It guarantees that every artifact, from source to deployment, is verified, traceable, and instantly accessible, regardless of where your teams are working.

These capabilities are exactly why more organizations are moving to modern, cloud-native platforms that combine speed, security, and scalability to support today’s software delivery demands - reasons we explore in detail below.

With legacy artifact repositories, engineering teams spend hours managing servers, applying patches, and juggling storage. A truly 

cloud-native artifact management platform

 is different from simply hosting a repository in the cloud—it’s built to auto-scale, self-update, and deliver continuous security without manual intervention. There’s no server downtime, no upgrade windows to schedule, and no need to plan for storage expansion - everything is handled seamlessly in the background.

Self-hosted systems cannot keep pace with the growth in artifact volume size. A cloud-native artifact management platform dynamically boosts its capacity to manage millions of artifacts across multiple teams, regions, and projects, 

Using elastic storage and edge caching CDNs, developers are always guaranteed a 

3. Built-in security and compliance from the ground up

In today’s world, threats move faster than ever. With malicious packages and supply chain attacks on the rise, cloud-native artifact repositories integrate vulnerability scanning, access controls, and SBOMs (Software Bill of Materials) directly into your pipelines.

This ensures that all artifacts maintained and shared are validated, trackable, and consistent with the industry regulations such as SOC 2, ISO 27001, and FedRAMP.

No extra patching or standalone security tools - modern artifact management 

 into every phase of your software supply chain.

4. Performance and speed that empower developers

A truly cloud-native artifact repository ensures artifacts are forwarded to the closest edge location, which significantly decreases both the time spent building and deploying, which has a direct impact on increasing developer productivity and CI/CD throughput.

Engineers can focus on building features rather than waiting on downloads or troubleshooting failed builds, making software delivery faster, more reliable, and predictable.

5. Seamless integration with the modern DevOps toolchain

Legacy repositories often require plugins or manual scripting to integrate with CI/CD tools. Cloud-native artifact management platforms offer native integrations with 

This ensures that artifacts flow seamlessly through your CI/CD pipelines, maintaining consistency, traceability, and reliability from development all the way to production.

6. Single visibility and governance between teams

In large organizations, artifacts are often scattered across multiple repositories and sometimes duplicated, making governance and visibility a constant challenge. A cloud-native artifact management system provides a centralized, single platform for managing visibility, audit, and access.

Administrators can also manage published, promoted, or consumed artifacts - to ensure compliance and reduce the risk of unauthorized access or obsolete dependencies.

In contrast to self-managed solutions that have unpredictable infrastructure charges, cloud-native artifact management follows a usage-based pricing scheme, which is predictable.

You pay for what you use. You do not expect to incur costs for hardware, maintenance, or downtime. This will ultimately lead to a reduced total cost of ownership (TCO) and a better understanding of the ROI of engineering time.

Moving legacy artifact management to a new, modern, cloud-native repository is not just a technical choice but a strategic one that enhances both the security, performance, and user experience of developing a product or service, as well as reduces costs in the long run.

Migrating from legacy artifact management to a modern, cloud-native repository improves security, performance, and the overall developer experience while helping reduce long-term operational costs. By centralizing control, simplifying scalability, and strengthening the software supply chain, teams can focus on building software more efficiently and securely.

How to upgrade from escape legacy artifact management (step-by-step)

The idea of moving away from on-premise or legacy artifact systems to a modern, cloud-native solution can be overwhelming, but with the correct plan, it is achievable.

Review what you store (packages, containers, Helm charts, etc.) and where.

Analyze utilization and access patterns -

 Learn which teams, pipelines, and tools rely on which repositories.

Select a modern artifact management platform – 

Seek capabilities such as universal format support, security scanning, policy management, global availability, and automation through integrations.

Migrate critical projects first, automate uploads, and validate integrations.

Once migration and validation are complete, phase out outdated systems to eliminate ongoing maintenance, reduce operational overhead, and free up resources for modern, cloud-native artifact management.

 Toolkit, combined with expert support, makes the transition seamless - preserving your history and metadata while enabling improved security and scalable infrastructure.

The real ROI of leaving legacy, on-premise artifact management behind

Teams that modernize and migrate to cloud-native artifact management see measurable returns:

Reduce infrastructure expenses by up to 60%.

Faster build and deployment times across CI/CD pipelines.

Improved developer satisfaction through simplified workflows.

Better compliance posture with automated vulnerability management.

Time spent maintaining a legacy repository directly impacts productivity and costs. Migrating to a modern, cloud-native artifact repository preserves operational efficiency and supports long-term software delivery improvements.

How Cloudsmith makes modern artifact management effortless

All of these challenges, including scalability, security, automation, and visibility, can be solved with a truly cloud-native approach to artifact management. And if you are planning a migration to the cloud, it is worth doing it right rather than sticking with your existing provider simply because it feels easier. A migration is already a major change, and it is the perfect opportunity to elevate your entire artifact management program. 

Cloudsmith was built from the ground up as a fully cloud-native platform that helps teams break free from the limits of traditional repositories, delivering seamless automation, built-in security, and scalable reliability in a single unified system.

Here’s how Cloudsmith enables that transition seamlessly:

 Cloudsmith is truly cloud-native which means hosting, scaling, and security are built in. Teams can focus on development without worrying about infrastructure maintenance and downtime.

 Whether you manage containers, packages, Helm charts, or custom binaries - with multi-format repositories, Cloudsmith provides one centralized platform for all your artifacts.

 Each artifact is scanned, signed, and tracked. Cloudsmith also has vulnerability scanning, dependency metadata, and SBOM generation built-in to ensure end-to-end security for your software supply chain.

 Artifacts are served over Cloudsmith’s global edge network and minimizing latency and providing fast and reliable builds across the globe.

 Cloudsmith integrates seamlessly with the latest DevOps platforms: GitHub Actions, GitLab CI, and Jenkins - enabling teams to automate artifact workflows, reduce manual errors, and accelerate software delivery.

A modern, cloud-native artifact repository like Cloudsmith simplifies operations, strengthens security, and accelerates software delivery - without the hidden costs or complexity of legacy systems.

Summary: don’t let legacy on-premise artifact management hold you back

Legacy artifact management is not only dated - it’s also costly, risky, and non-sustainable. The emerging generation of cloud-native artifact management platforms, such as Cloudsmith, transcends complexity with confidence, enabling teams to achieve the visibility and velocity required to build securely at scale.

The faster you retire legacy systems, the sooner your organization can build securely, on a truly modern, cloud-native platform.

1. What is legacy artifact management, and why is it a problem?

The management of legacy artifacts encompasses older systems (typically 

) used to store and distribute software packages. Such systems do not offer the automation, scalability, and integrated security that are needed in modern DevOps, resulting in inefficiencies and increased operational costs.

2. What are the unknown expenses of legacy artifact repositories?

Beyond licensing, teams also bear the costs of infrastructure maintenance, downtime, manual updates, and security risks. These hidden expenses can quickly add up, often exceeding the investment required for a modern, cloud-native alternative.

3. How do I migrate to a modern artifact repository?

Begin by auditing your existing repositories, determining dependencies, and automating the migration with the help of migration tools (such as Cloudsmith’s Migration Tool). The advantage is to retain the integrity of artifacts with the purpose of avoiding manual management.

4. Why choose a cloud-native artifact repository over self-hosted options?

Uptime, scaling, and security are automatically managed on cloud-native platforms. They are CI/CD integrated, can distribute faster worldwide, and can eliminate maintenance overhead, allowing your developers to focus on their core tasks

5. How does modern artifact management improve security and compliance?

Modern artifact systems integrate vulnerability scanning, SBOMs generation, and access control. This will ensure artifacts are secure, traceable, and compliant – which is essential to securing your software supply chain.

The true cost of legacy artifact management

You've planned your migration to Cloudsmith: you know you need hybrid

, granular access controls, retention policies and vulnerability scans.

However, there is one foundational decision that must be settled first, because it underpins all subsequent security and distribution configurations: setting up custom domains for your package distribution.

While it may appear to be just another configuration option - custom domains are fundamental to establishing trust, security, and professional credibility in your software supply chain. Let's explore why.

What are custom domains as they relate to artifact management?

By default, when you access packages from Cloudsmith, your URLs follow a pattern that includes Cloudsmith's domain. With custom domains, you replace this with your company's own subdomain - something like docker.artifacts.yourcompany.com or packages.yourcompany.com. It's a simple DNS configuration that creates a profound shift in how your artifact distribution is perceived and secured.

Why would you want to use a custom domain?

When distributing software - whether to internal developers or external customers, using your own domain reinforces your brand at every touchpoint. Consider the developer experience: which feels more trustworthy? A third-party domain with your organisation name embedded in the path, or a clean domain that's clearly part of your company's infrastructure?

The custom domain maintains a professional appearance across all distribution channels and eliminates confusion about software authenticity. Many team members and customers may not even know (or need to know) that you're using Cloudsmith under the hood. Using your own domain reassures they're accessing an authoritative source directly from your organisation.

While branding matters, security is where custom domains truly shine. The benefits span multiple layers:

 is perhaps the most immediate advantage. Custom domains place you on dedicated CDN infrastructure with workspace-specific rate limits. Unlike shared Cloudsmith domains where you're subject to general limits alongside all other customers - custom domains allow you to configure rate limits that match your company's legitimate traffic patterns. This is particularly valuable during migration when transferring large volumes of packages, but it's equally important post-migration, for protecting against denial-of-service attacks with customised thresholds.

 becomes dramatically easier with custom domains. They integrate seamlessly with your security infrastructure, allowing you to monitor traffic patterns specific to your domain in firewall and proxy logs. You can integrate these metrics directly into your SIEM and monitoring tools like Datadog, set up domain-specific alerts and anomaly detection, and track DNS queries in your own logs. This visibility is invaluable for detecting unusual access patterns or potential security incidents before they become problems.

Finally, custom domains offer a simplified URL structure that 

. By removing your Cloudsmith organisation name and/ or repository name from URLs, you lower the risk of

 - a common attack vector where malicious actors register lookalike domains to hijack traffic. With a dedicated, simplified domain, there's far less chance of a mistyped link leading somewhere it shouldn’t.

Best Practices for Implementing Custom Domains for Artifact Management

As you plan your custom domain strategy, several key considerations will help ensure success:

Not all package formats work the same way. Formats like Docker, npm, and NuGet have native API protocols and can use format-specific custom domains. However, formats like Debian, RPM, and Helm rely on static file downloads and need a single catch-all download domain. This distinction matters, because native API formats communicate through structured API calls, while download-only formats construct file paths from metadata files.

Trying to set up format-specific domains for download-only formats creates debugging nightmares - packages become accessible through multiple domains inconsistently, and metadata may reference different URLs. Document your domain pattern clearly for your team so they know which URLs to use and can troubleshoot effectively.

Most customers benefit from account-level domains that work across all repositories in your Cloudsmith organisation. This approach simplifies governance and reduces configuration overhead, making it ideal for organisations with centralised artifact management.

However, per-repository domains make sense when distributing different products to different customers or when you need fine-grained control and branding per product line. This approach works well for multi-tenant scenarios where each product needs its own identity.

Custom domains are the final, essential step in taking full control of your software supply chain. By implementing custom domains with Cloudsmith, you are fundamentally investing in:

Control: Complete network-level visibility, monitoring, and tailored rate limiting.

Security: A defined security boundary that tightens your perimeter and protects against common attack vectors.

Brand: A professional, consistent customer experience that actively enforces trust

Artifact distribution: Securing the trust with your own domain

For most developers, the traditional security pipeline is a source of friction, not a tool for enablement. You push a new feature, the CI build kicks off, and suddenly you're facing a wall of 1,200 critical CVEs from a transitive dependency you didn't even know you had. The release is blocked, and the security team becomes the "Department of No" - a metaphorical bottleneck that seems to exist solely to slow down velocity. This dynamic is broken. The goal isn't to have 

 security; it's to have smarter security that enables speed; that requires moving from noisy alerts to prioritised, actionable risk.

" culture is a direct result of missing context. When a security team sees a thousand CVEs, they have to assume all are critical. Without clear software provenance, every new dependency is a potential "

" - an unaudited package that could be anything from a benign tool to a typosquatted nightmare. An SBOM (Software Bill of Materials) provides the "what," but it doesn't provide the "so what?" This is why developers get buried in alerts for vulnerabilities that aren't even reachable in their code. To fix this, you need a system that doesn't just find problems, but also provides the context to 

This is where the pipeline needs to get smarter, starting at the build. A tool like 

 integrates directly into your CI pipeline to provide this missing context 

 an artifact is ever created. Its job isn't just to find every CVE; it's to intelligently triage them. By performing context-aware analysis, it determines if a vulnerability is 

 within your application's call path. This is the practical power of 

 (Vulnerability Exploitability eXchange) reporting. That jaw-dropping list of 1,200 CVEs becomes a manageable, actionable list of something like 

 that can genuinely pose a threat. Kusari acts as the guardian of the build, generating a tamper-proof evidence packet containing a signed SBOM, a VEX report, and a provenance attestation, ensuring you only build what you trust.

Once Kusari verifies a build and signs its evidence packet, the artifact can be pushed to the Cloudsmith artifact repository. Cloudsmith isn't simply a passive vault, it also serves as an intelligent admission control layer via Enterprise Policy Management (

 offering allows users to quarantine packages with a deep-level of context. This is where you set the rules: "Block any artifact with a non-compliant license from being pulled," or "Prevent any package with a critical-severity CVE from being deployed to production, if we know there’s a fix already available." It gives you the "last mile" of control, ensuring that only verified, secure, and compliant artifacts are distributed and consumed by developers and production systems.

This combination of Kusari and Cloudsmith creates a closed-loop security system that finally busts the "Department of No" myth. For developers, this means an end to the noise. You get fast, actionable feedback directly in your CI pipeline, allowing you to fix the five critical, reachable vulnerabilities instead of arguing about the 1,200 that aren't. For the organisation, it means security transforms from a reactive bottleneck into a proactive, automated discipline. You can trust that anything you pull from Cloudsmith is pre-vetted, and security teams have an end-to-end, auditable trail from source to deployment. This is how you stop fearing security and start automating it, enabling your team to ship with confidence and speed.

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

KubeCon + CloudNativeCon North America 2025 is almost here, bringing together thousands of developers, security leaders, and platform engineers, to explore the latest in cloud-native technology. With dozens of talks, workshops, and keynotes across multiple tracks, it can be tough to know where to focus your time. To help, we’ve curated a list of 

 covering security, AI, cloud-native innovation, and platform engineering - including some interactive, hands-on experiences.

Georgia World Congress Center, Atlanta, GA

1. Kong AI gateway & insomnia workshop: AI success through API heroics

 Embassy Suites by Hilton Atlanta at Centennial Olympic Park

 is hosting this hands-on workshop exploring how AI-driven APIs can streamline workflows and improve automation. Attendees will work with Kong’s API Gateway and Insomnia tools to see practical examples of AI integration in real-world projects. If you’re curious about how Kong secures its software supply chain while supporting modern development practices, check out their 

2. Project lightning talk: The same great OPA, only faster

 Building C | Level 3 | Georgia Ballroom 2

 performance, demonstrating how teams can implement faster, more efficient policy-as-code pipelines. Learn tips and tricks for maintaining security and compliance at scale, while reducing the friction often associated with enforcing policies in CI/CD pipelines.

3. Capture the Flag challenge: Defend the pipeline

 Hilton Garden Inn Atlanta Downtown | Atlantic Room - 2nd Floor

 where you’ll defend a CI/CD pipeline against realistic attack scenarios. Participants can test their skills against malicious packages, misconfigurations, and supply chain threats, all in a safe, gamified environment. This session is a great way to see security best practices in action and get hands-on experience defending a modern software pipeline.

4. Keynote: Supply chain reaction - a cautionary tale in K8s security

This keynote examines lessons learned from major supply chain attacks and highlights how Kubernetes environments can be hardened against similar risks. Security leaders and DevOps teams will gain actionable insights on improving artifact integrity, detecting threats early, and reducing downstream risk across CI/CD pipelines.

5. Keynote: Maximum acceleration - Cloud Native at the speed of AI

Adobe’s Joseph Sandoval explores how cloud-native architectures can be optimized for AI-driven workloads. The session covers practical strategies for designing infrastructure that can scale dynamically, accelerate development cycles, and maintain operational reliability while supporting AI initiatives across the enterprise.

6. Taming the complexity beast: Rethinking software architecture & deployment

This session brings together engineers from Chainguard, IBM, and other organizations to share how they simplify complex architectures and streamline deployments. Learn practical approaches for reducing operational overhead, improving reliability, and supporting fast-moving development teams across multiple platforms.

7. Platform Engineering day zero: The origin story

Google’s Murriel McCabe shares a blueprint for building scalable platform engineering teams from scratch. Attendees will learn how to structure teams, select tooling, and define processes that maximize productivity and maintain developer velocity from day one.

8. Keynote: There’s nothing to fear about the EU’s new Cybersecurity Law

Linux Kernel maintainer Greg Kroah-Hartman explains the implications of the EU’s new cybersecurity legislation for open-source projects and enterprise security teams. This session is essential for anyone responsible for compliance or managing public and private codebases.

9. Turn up the heat: Driving cloud-native innovation into real-world impact

Learn from real-world examples of how organizations are accelerating innovation while maintaining secure, reliable cloud-native deployments. This session highlights strategies for balancing velocity with compliance, and how cloud-native principles can drive tangible business outcomes.

10. The hidden risks in AI/ML supply chains: How to secure your workloads

 Building B | Level 5 | Thomas Murphy Ballroom 1

Yash Pimple from Chainguard explores the emerging security challenges in AI/ML pipelines, including model provenance, dependency risks, and how malicious artifacts can propagate across environments. Attendees will get actionable guidance on securing AI workloads in production.

11. Cloud-native back to the future: The road ahead

Microsoft and Akamai leaders discuss the evolution of cloud-native practices, including modern tooling, automation strategies, and architectural patterns that will define the next era of software delivery.

12. Ulysses: Odyssey through platform engineering

William Rizzo of Mirantis takes attendees on a deep dive into platform engineering maturity, sharing lessons learned, best practices, and practical advice for building reliable developer experiences at scale.

13. Mapping the next phase: Updating the Cloud-Native maturity model for 2025

Akamai, StackEgy, and Glennium explore how cloud-native maturity models are evolving in the AI era and what this means for teams designing future-ready infrastructure. This session is ideal for technical leads planning long-term

 at KubeCon + CloudNativeCon 2025! Gain insights from booth lightning talks, get hands-on with live demos, and swap ideas with engineers solving the same challenges you are. Our team will be on hand to demo our cloud-native artifact management platform, answer your questions, and share tips on securing your software supply chain, AI artifacts, and CI/CD pipelines. We can’t wait to connect with you in person and explore how Cloudsmith can help your teams move faster, stay secure, and embrace modern development practices.

13 sessions not to miss at KubeCon and CloudNativeCon 2025

Artificial intelligence has moved beyond a futuristic concept to a daily collaborator for almost all development teams today. Tools like GitHub Copilot and ChatGPT are writing functions, suggesting dependencies, and building application skeletons at a blistering pace. This revolution in speed is undeniable, but it comes with a critical, often-overlooked consequence: AI-generated code is fundamentally changing the demands on artifact management.

We're moving faster than ever, but that speed has created massive blind spots in our software supply chain. The core question is no longer just "

Does AI check its sources and provide provenance checks?

Let's address the first fundamental question. When an LLM suggests a software package or a new dependency, does it perform 

" if a dependency is credible, accurate, or safe. It's not testing that package in a sandbox. It's making a statistically probable recommendation based on the data it was trained on.

This creates a terrifying new attack vector. The AI has no concept of:

, pulling in a malicious package. Oftentimes it depends on what you ask for, and sometimes you get exactly what you asked for - whether that’s a good package or not.

: AI can't scan a dependency for malware before recommending it. After the ‘s1ngularity’ and ‘

’ attacks on the NPM ecosystem, there is a heightened focus on understanding the contents of open-source packages that we consume from these upstreams.

: AI doesn't differentiate between a well-maintained library from a trusted foundation like the CNCF vs. an abandoned, vulnerable package from a random user that likely will not be actively maintained going forward.

If a developer accepts that suggestion, a compromised dependency is instantly pulled into the codebase, bypassing all traditional human vetting.

Typosquatting is a type of cybercrime where attackers register domain names, or in this case dependency names, that are common misspellings or slight variations of legitimate websites/packages/dependencies to trick users into visiting a malicious site or downloading a software dependency that ultimately contains malware. A perfect example is the 

 example we mentioned earlier. One extra letter and many users wouldn’t immediately recognise it as a typo. Let’s query PyPi to see the owner of both packages:

 (AKA bitprophet). Whereas, the typosquatted package name returns “

” for the owner. You’ll have probably noticed by now that this package no longer exists on PyPi as it was intentionally created to cause harm - and has since been removed. While that’s good for the community, there’s a chance that an organisation may have already cached that package locally. In those cases, the OSV.dev public API can be really useful to identify whether your cached dependencies were created as part of a typosquatting campaign:

So what’s all this got to do with generative AI? Well, GenAI is just as guilty of hallucinating and recommending package names that simply don’t exist. Adversaries pick up on the behaviour, and thus create more typosquatted upstream packages in the hope that “

” code generation recommends one of those typosquatted package names. This is commonly known as 

. To stay ahead of slopsquatting, modern artifact management are expected to have full provenance checks on all software artifacts to understand who created them, are they credible, and have they already been flagged as compromised according to the 

Malware, unlike vulnerabilities in software, is a dedicated piece of software that is specifically designed to disrupt, damage, or gain unauthorised access to a computer system. Traditional vulnerability scanners are looking for flaws in an application code that can be exploited. These are marked by CVEs (like 

). However, malware contained within compromised upstream packages will not show-up in those CVE reports. Instead, we can use the same OSV.dev public API to see if an open-source upstream package, such as 

After running this command, you see that the package is identified as containing malware, with a unique identifier - 

. Now you couldn’t be expected to run this manual action every time you want to check if a specific dependency and version contain malware, that would take all day. Thankfully, Cloudsmith integrates the 

 API directly within our product. So on package synchronisation, we will automatically scan for known Malware identifiers (ie: MAL-YEAR-ID) associated with the open-source software dependency. If there’s a match, we can quarantine this automatically through 

Most recently, a variant of PhantomRaven malware was found in 

, designed to steal GitHub Tokens from developers. If LLMs cannot quickly identify whether an upstream package is compromised or not, what stops these generative AI tools from suggesting compromised packages? As the prevalence of malware in upstream repositories increases, this simultaneously changes the demands being put on artifact management. Modern artifact management solutions need to be able to identify and prevent compromised open-source software packages from being used by developers.

AI models used for code generation are trained on vast, uncurated datasets of public repositories, learning statistical patterns rather than semantic quality. This training methodology makes them incapable of assessing 

. The model does not understand that a CNCF-hosted project undergoes rigorous security audits, has a dedicated maintenance team, and follows a clear governance model. To the AI, that project's code patterns may look statistically similar to an abandoned, single-maintainer package on GitHub that contains known CVEs or is a prime candidate for a typosquatting attack. This "

" means the AI's suggestions are based on pattern frequency, not on a risk assessment of the dependency being recommended.

This blind spot directly reflects the current software supply chain risk. An AI can confidently recommend a dependency that, while functionally correct for the prompt, introduces significant security debt. This is backed up in the data. Chainguard’s "

" found that 1 in 5 respondents said that their engineers are not allowed to use AI for some of the most time-intensive tasks, such as patching vulnerabilities, running tests, or conducting code reviews. These are the tasks where technical credibility is needed to make those final judgements.

Furthermore, AI models trained on these OSS software ecosystems will inevitably learn from and recommend historically compromised packages from those upstreams. This problem is recognised by security foundations like OWASP, whose "

" lists risks like "Insecure Output Handling" (LLM03) and "Training Data Poisoning" (LLM04), where the model's output or its training data can be leveraged to inject vulnerabilities directly into a developer's workflow.

Ultimately, the credibility of these outputs can be benchmarked against frameworks such as the 

. This project was built by open-source developers to help secure the critical projects the community depends on. It assesses open-source projects for security risks by running a series of automated checks. You can use it to proactively analyse the security posture of your own code and make better-informed decisions about acceptable risks. The tool also helps you evaluate other projects and dependencies, giving you a basis to work with LLMs on improvements before you integrate into your codebase.

Does this mean we should be discouraged from using AI-generated code?

The short answer is 'no,' but a cautious and deliberate approach is essential.

We view generative AI much like any other programmable interface. It excels at following instructions, which means the quality of the output is directly dependent on the quality of the input.

A developer who is skilled in their domain will understand how to instruct the AI to produce high-quality, relevant content, thereby accelerating their workflow. For example, knowing precisely which software packages and versions are appropriate for a production application prevents the AI from referencing and introducing compromised dependencies.

By providing specific context, such as example code, the application framework, established code styles, library usage, specific dependency versions, and error handling protocols, a developer can guide the AI. This ensures it follows established rules and helps produce code significantly faster than manual methods.

Regardless of popular sentiment, our view is that generative AI is not close to replacing human intelligence in software development. Its current, practical role is to speed up and facilitate the quality work humans do, ultimately increasing overall productivity.

This new power, however, requires a corresponding increase in diligence for software governance, provenance checks, and vulnerability scanning. Maintaining control over AI-generated code means knowing exactly what is running in the estate, who created it, and being confident whether it is safe or not. This is all achievable through a comprehensive artifact management platform. If you’d like to learn more about this, we have an 

 on the topic of slopsquatting in the age of GenAI.

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

When a region in the Cloud goes down, it impacts people everywhere. Engineers are stressed. PagerDuty is screaming. People are asking questions. That’s not the moment to blame your Cloud provider or write cynically about single-cloud risks. It’s time to knuckle down and take responsibility.

On Monday, October 20th, 2025, a large part of the internet blipped in and out of existence. One of AWS’ busiest regions, us-east-1, went dark. A single DNS bug inside DynamoDB snowballed into hours of failures worldwide. The list of affected services was absurd: PlayStation, Snap, Disney+, Slack, Zoom. And the weird ones: VAR decisions in the Premier League and the inability to control Eight Sleep beds. It hit some harder than others, but even companies built for ultra-high availability, like Vercel and our own Cloudsmith, saw some impact.

Cloudsmith Blog

What is Software Supply Chain Integrity?

Extend EPM policies to Hugging Face artifacts

Shai-Hulud: The Second Coming - What You Need to Know and Do Now

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

The DevOps Guide to Mitigating Software Supply Chain Risks

Kubernetes 1.35 – What you need to know