By submitting this form, you agree to our 

The adoption of artificial intelligence is seen in just about all industries, with software engineering experiencing large benefits from AI assistants. Tools like Anysphere’s 

 are driving a fundamental shift in how engineering teams build and ship software. However, as development teams rush to integrate LLMs and generative capabilities into their products, a critical blind spot is emerging in the software supply chain.

While security teams have spent years fortifying their pipelines against vulnerable Docker images and malicious npm packages, the introduction of AI artifacts (specifically ML models and their associated datasets) has opened a new, largely ungoverned frontier for software development teams. The challenge is no longer just about securing the code you write, but about verifying the provenance and integrity of opaque binary blobs that are often pulled directly from public repositories into production environments.

 has become the de facto standard for discovery and storage, playing a role similar to what 

 for containers. It is a massive, thriving community where developers can easily download pre-trained checkpoints, fine-tune them with 

, and deploy them via inference endpoints. Yet, the very openness that makes these platforms engines of innovation also introduces significant risk. Just as software engineering leaders would never want or allow a developer to pull an unverified executable from the open web directly into their banking application, they must stop treating these ML models as benign assets during this new age of AI software development. These are executable artifacts that require the same rigour, scanning, and governance as any other critical dependency in the software stack.

The most pressing concern facing development teams today is the specific architecture of these models, particularly regarding "

". Pickle files are Python-based modules used to serialise and deserialise code, a standard method for storing trained ML models. However, this format is inherently insecure by design. Threat actors have weaponised this necessity, embedding malicious payloads that execute arbitrary Python code during the deserialisation process. Security researchers have already identified hundreds of malicious models on public hubs that utilise these techniques to deploy web shells or execute remote code evasion tactics. While platforms like Hugging Face are proactively deploying 

 tools and warning users, the sheer volume of community uploads means that reliance on the public source alone is an insufficient security posture for the enterprise.

Furthermore, the security challenge extends beyond the model itself to the ecosystem that supports it. An AI project is rarely just a model file; it is a complex dependency tree involving Python packages, libraries like 

 (tool for building and deploying AI-powered agents and workflows) or 

 (OpenAI's Text-to-Image Transformer), and various system-level binaries. A secure model running on top of a vulnerable version of a Python library offers a wide-open door for attackers. Therefore, true AI supply chain security requires a holistic approach that governs the model, the dataset, and the OSS dependencies simultaneously. If you are scanning your models for malicious pickles but failing to check the 

 of the Python packages they rely on, the supply chain remains broken.

This is where the concept of a centralised system of record becomes non-negotiable. To mitigate these risks without stifling innovation, software engineering, DevOps and security teams must implement some sort of architecture of isolation and control. This involves 

 public registries. By placing a controlled layer between the developer and the public internet, dev teams can ensure that every artifact (whether it is a Docker image, a Python package, or a Hugging Face model) should be scanned for malware, vulnerabilities, and license compliance before it ever enters the internal network. This allows developers to use standard CLI tools and workflows they love, while security teams enforce policies in the background, quarantining suspicious artifacts before they can cause harm.

 approaches this challenge by extending traditional artifact management to include the specific nuances of AI and ML workflows. By providing a single point of control, Cloudsmith allows enterprises to manage ML models alongside their existing software packages, creating a unified source of truth. The platform proxies and caches external sources like Hugging Face, automatically stripping out risks and verifying provenance. This ensures that when a developer runs a command to pull a model, they are receiving a version that has been vetted against enterprise policy and validating trustworthiness. It bridges the gap between the data science team’s need for speed and the security team’s need for governance.

Ultimately, the future of secure AI development lies in consolidation. The separation of "

" is a dangerous dichotomy. As AI becomes intrinsic to application development, the distinction between a code dependency and a model dependency vanishes. By utilising a platform like Cloudsmith to centralise access control, enforce read-only entitlement tokens, and automate policy management, platform engineers can protect their organisation’s intellectual property and their infrastructure. It turns the supply chain from a vector of attack into a controlled, observable pipeline, ensuring that the only thing your AI models deliver is value. If you’d like to learn more about Generative AI threats like Slopsquatting, register for our 

Typosquatting & Slopsquatting: Detecting and defending against malicious packages webinar

Nigel Douglas

Head of Developer Relations

Software Supply Chain Security in the Age of AI

Securing the intersection of AI models and software supply chains

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.

Parul Jhawar

Marketing

 101 Leave Legacy Behind

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

Agnė Gasparavičiūtė

Customer Success Architect

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.

Claire Speedy

Senior Marketing Manager

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 “

Cloudsmith Blog

Securing the intersection of AI models and software supply chains

The true cost of legacy artifact management

Artifact distribution: Securing the trust with your own domain

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

13 sessions not to miss at KubeCon and CloudNativeCon 2025

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

The 3Rs of Critical Infrastructure: Responsibility, Resilience, and Reality

The Hybrid Repository Structure: Balancing Control and Flexibility

Using vulnerability scoring systems to prioritize risks in your environment

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

Python 3.14 – What you need to know

7 Ways Cloud-Native Improves Artifact Management Scalability and Performance