By submitting this form, you agree to our 

Building trust from source to ship

 is a software supply chain weakness that arises from how package managers resolve dependencies across multiple sources.

It does not rely on complex exploits. It relies on normal dependency resolution.

If a build resolves from both private and public registries, and a public package shares the same name as an internal dependency, the public package may be selected. That is sufficient to introduce unintended code into a build.

Modern dependency trees often include extensive transitive dependencies, increasing the number of automatic resolution decisions made during builds.

when researchers demonstrated it against more than 35 large organizations by publishing public packages that matched internal names. Since then, dependency confusion has remained a known and preventable risk in modern build systems.

If resolution rules are not explicit, package managers make decisions on your behalf.

Different ecosystems provide different structural protections and different pitfalls.

PyPI operates on a flat global namespace. There are no built-in organizational scopes and no domain bound identifiers. Package names are globally unique and first come, first served.

This means internal package names, for example acme utils or internal ml core, are structurally indistinguishable from public ones unless additional controls are applied.

Python projects frequently configure multiple indexes. It is common to see:

Vendor-hosted repositories such as PyTorch wheel indexes for CUDA builds

Python tooling such as pip, uv, and Poetry evaluates candidate versions across configured sources. If the same package name exists in more than one index, the resolver may select the highest compatible version, regardless of origin.

Real-world incidents demonstrate this behavior. 

In 2022, a malicious package mimicking a PyTorch dependency

 was published to PyPI and installed via pip resolution during nightly builds, leading to data exfiltration before detection.

Without explicit trust boundaries or source mapping, this multi index behavior introduces ambiguity. If an internal package name is exposed and a higher version appears on a public index included in resolution, the public package may be selected.

Python’s flat namespace model, combined with common multi index configurations, makes careful source control particularly important.

npm supports scoped packages using the @org/package format. Once registered, a scope is controlled by that organization.

However, unregistered scopes remain claimable. If an organization uses scoped internal packages but has not reserved the scope publicly, an attacker could register it and publish similarly named packages, for example @org/app. A configuration mistake in development or CI could then result in the malicious package being resolved and executed, including via lifecycle hooks such as preinstall.

Unscoped internal package names carry exposure similar to Python.

Maven Central uses domain-based groupId verification, providing stronger ownership guarantees when correctly configured.

However, inconsistent repository usage or additional repositories can reintroduce ambiguity in resolution order if trust boundaries are not clearly defined.

While NuGet supports ID prefix reservation to prevent public name squatting, resolution ambiguity can still arise if multiple feeds are configured.

ID prefix reservationReserve your organization’s package ID prefix on nuget.org to prevent public impersonation.

Package Source Mapping Use NuGet 6+ source mapping to bind specific package IDs or prefixes to a single trusted feed.

Strict nuget.config configurationClear default feeds and explicitly define approved sources to prevent unintended restores.

Signature enforcementNuGet repository signing using X.509 certificates. When signature verification is enforced in the NuGet or .NET CLI, consumers can verify that a package originated from the expected repository and has not been tampered with.

Docker Hub differs from language ecosystems because image references are typically registry qualified, making classic multi-source confusion less common.

Implicit Docker Hub fallback when no registry is specified

These are mitigated through fully qualified image references, namespace reservation, digest pinning using SHA256, and image signing.

Preventing dependency confusion does not require dramatic changes to developer workflows. It requires clear trust boundaries in how dependencies are resolved.

In practice, this is implemented through an internal artifact repository that controls how dependencies are proxied, cached, and resolved.

Enforcing artifact signing and verification

Route all builds through a central artifact repository that acts as the single source of truth for dependencies. Public packages should be proxied and cached internally rather than resolved directly from the internet.

Explicitly distinguish between trusted and untrusted sources.

Cloudsmith provides upstream trust controls that allow repositories to designate upstream sources accordingly and control how packages are blended during resolution. If a package exists in a trusted source, it cannot be overridden by an untrusted one.

Cloudsmith’s Upstream Trust currently supports:

Support for additional ecosystems is expanding. In addition to source trust controls, policy enforcement provides another layer of protection. 

 allows organizations to define rules around what packages are permitted, including conditions based on vulnerability data, malware data, version constraints, or upstream origin. This enables teams to combine resolution boundaries with policy-based controls.

Namespace ownership significantly reduces collision risk.

Lockfiles improve determinism, traceability, and visibility into unexpected changes. They do not eliminate dependency confusion, but they reduce instability and make tampering easier to detect.

Signing adds cryptographic integrity to artifacts.

Cloudsmith signs hosted packages by default. Cloudsmith supports both native and non-native signing across package formats, including native signing for 

. Signature validation workflows in supported ecosystems provide an additional verification layer if substitution is attempted.

Signing strengthens integrity guarantees but does not replace resolution controls.

Dependency confusion is not a sophisticated exploit. It is a consequence of ambiguous resolution behavior across multiple sources.

A central artifact repository serving as the single source of truth for dependencies

Clear boundaries remove ambiguity. Removing ambiguity removes the attack path.


Stop leaving your build integrity to chance. 

 today to see how Cloudsmith's enterprise-grade repository controls can remove ambiguity and harden your delivery process.

Ciara Carey

Solutions Engineer

Dependency confusion and trust boundaries in modern builds

Thousands of platform engineers and security experts are about to gather for KubeCon + CloudNativeCon Europe 2026, making it the year’s definitive cloud-native event. To help you cut through the noise of a packed agenda, we’ve identified the standout sessions you can’t afford to miss. Whether you're looking for high-level strategy or interactive workshops, here is our curated roadmap to ensure you get the most out of your time on the ground.

📍 RAI Amsterdam (Europaplein 24, 1078 GZ Amsterdam, Netherlands)
🗓️ March 24 - 26, 2026

 (Thales SIX GTS France) will dive into the messy reality of the Software Bill of Materials (SBOM). They plan to pull back the curtain on why current open-source and cloud-based tools (despite all their promises) frequently generate conflicting package lists and inconsistent vulnerability reports when tasked with scanning complex container images.

This talk is particularly electrifying for the security community because it tackles the compliance anxiety triggered by the EU’s Cyber Resilience Act (CRA). As the CRA shifts SBOMs from a nice-to-have transparency initiative to a legal necessity for software lifecycles, the industry is waking up to a major problem, which is inconsistent data. By dissecting the technical roots of these discrepancies, Bufalino and Blaise aren't just pointing out flaws, they will also be providing a roadmap for developers to ensure their tooling is actually CRA-compliant. For anyone navigating the shift toward a transparent and trustworthy software supply chain, this session offers the technical clarity needed to turn these metaphorical bombs into secure builds.

2. Modelpack: Standardising the packaging and distribution of AI/ML Models

, a Distinguished Architect at Red Hat, tackles one of the most pressing bottlenecks in modern infrastructure: the chaotic fragmentation of AI/ML integration within the cloud-native ecosystem. Block, a seasoned expert in helping organisations scale open-source solutions, will break down how the current wild west of competing formats and runtimes is actively stifling innovation. He will introduce 

, a CNCF Sandbox project designed to act as the universal translator for AI/ML artifacts, allowing them to finally speak the same language as established tools like Kubernetes, ORAS, and Harbor.

The security and DevOps communities are closely watching this session because it addresses the Day 2 operations nightmare of managing AI at scale. As AI moves from experimental notebooks to production-grade Kubernetes clusters, the lack of standardisation creates massive technical debt and security blind spots. Block’s exploration of ModelPack and emerging artifact standards offers a glimpse into a future where AI models are managed with the same consistency and rigour as container images. For anyone struggling to bridge the gap between data science and cloud-native engineering, this talk provides the blueprint for a unified, scalable, and manageable AI supply chain.

3. Kubernetes security at Shopify scale: Automating security across an infrastructure monrepo

In this session, Senior Infrastructure Security Engineers 

 will pull back the curtain on how one of the world’s largest e-commerce platforms secures its massive infrastructure monorepo. Drawing from their deep backgrounds in cloud defense and 5G network security, Wu and Garg will detail the high-stakes challenge of managing thousands of services where a single misconfiguration could impact millions of merchants. They will demonstrate how Shopify moved beyond manual checkbox security by building an automated pipeline that combines Semgrep for static analysis and Open Policy Agent (OPA) for real-time policy enforcement.

This talk is a must-attend for the security community because it provides a battle-tested blueprint for solving the velocity vs. security dilemma we’re all too familiar with. While many orgs struggle with friction between DevOps and Security teams, Shopify’s approach shows how to bake guardrails directly into the developer workflow without slowing down deployment. Attendees will gain rare insights into the so-called rough patches of scaling open-source security tools and leave with a practical framework for automating risk detection across complex, high-traffic Kubernetes environments.


4. To upstream or not? Why becoming the maintainer of your dependencies matters

, a Principal Software Engineer at Elastic and an OpenTelemetry code owner, dives into the strategic heart of modern software engineering. Markou moves beyond the typical 

 narrative to present a pragmatic, business-first case for active maintenance. By sharing a high-stakes story of an OTel component saved from the brink of deprecation, he demonstrates how moving from a passive consumer to an active contributor transformed a potential technical debt nightmare into a rapid-response tool for solving critical customer issues.

This talk is a vital wake-up call for the security and observability communities because it addresses the growing crisis of software supply chain sustainability. In an era where a single abandoned dependency can lead to massive security vulnerabilities or operational outages, Markou provides a concrete example to share with your manager on why upstreaming isn't just altruism, it also can be treated as sensible risk management. For teams building on CNCF projects, this session offers a masterclass in how staying present in the ecosystem pays dividends in architectural control, security posture, and long-term engineering velocity.


5. How to add a new language feature to OPA

Adding features to a widely adopted language like Rego involves more than just a simple pull request. In this lightning session, Apple's 

 explores the full-stack impact of introducing new syntax, from the initial parser modifications to updating the broader ecosystem of editor tools. Learn the specific engineering hurdles involved in upgrading a mature security project without disrupting the developer experience. At Cloudsmith, we’re huge fans of Open Policy Agent and Rego, so we can’t wait to hear what Charlie has in store for us.

6. Platform Engineering 2.0: Just-enough Kubernetes and AI-native DevOps

 and a seasoned authority on platform patterns, tackles the industry's growing complexity bloat. Drawing from 20 years of experience and the literal scars of re-architecting internal platforms at one of the world’s largest travel sites, Vohra argues that the future of infrastructure isn't about building more, it’s really about building just enough. She will break down how to transition from heavy, static systems to lean, right-sized architectures using k3s, Gateway API, and ambient mesh, while layering in AIOps via Kubeflow and Prometheus to transform raw automation into true system intelligence.

This talk is a critical touchstone for the DevOps and platform communities because it offers a pragmatic exit ramp from the scale at all costs mentality that leads to massive cloud waste and operational blindness. Vohra’s AI-native approach is a blueprint for creating self-optimising ecosystems that align infrastructure directly with business value. For engineering leaders and architects feeling the weight of over-engineered clusters, this session aims to be a masterclass in staying lean, staying smart, and evolving platforms to be adaptive rather than just additive.

7. AI Agents & Platform Engineering: Efficiency boost or new source of trouble?

In the blockbuster panel, an elite group of industry leaders from 

 converges to debate the most disruptive shift in DevOps history. Featuring heavyweights like from the industry, this vendor-neutral discussion moves past the hype to ask the hard questions: Can non-deterministic AI agents actually keep pace with AI-accelerated developers, or are we just inviting unpredictable trouble into our production clusters? The panel will tackle the minimum viable platform foundation required for AI success, the shifting cost implications of agents in production, and how to build human trust in systems that don't always behave the same way twice.

This session is arguably the must-see event for the modern platform engineer because it addresses the looming intelligence gap in infrastructure. As developers pump out code at record speeds, the platform team is traditionally treated as the bottleneck. This panel explores whether AI agents are the ultimate scaling solution or a new category of technical debt. By bringing together perspectives from global tech giants and international organisations, attendees will walk away with a high-level framework for defining golden metrics for AI effectiveness and a roadmap for navigating the transition from static automation to dynamic, agent-led collaboration.

8. In Falco’s nest: The evolution of cloud native runtime security

In the maintainer track session, Falco contributors 

 (Kong) provide a deep-dive update on the CNCF’s de facto standard for runtime threat detection. The core of their presentation focuses on the highly anticipated Falco Operator, a game-changer designed to automate the deployment and management of security sensors across massive, distributed clusters, effectively lowering the barrier to entry for enterprise-scale security.

For the security community, this talk is a vital look at the roadmap for high-throughput runtime defense. As cloud-native environments become more complex and data-heavy, traditional security tools often struggle with performance overhead; Rozzo and Lacuku will demonstrate the specific optimisations that allow Falco to maintain deep visibility without sacrificing system reliability. Beyond the code, this session also is a great opportunity to see how the Falco ecosystem is integrating with the broader CNCF landscape, offering attendees a first look at the features that will define Cloud Detection & Response (CDR) in the coming year.

9. What LLMs do, and don’t, know about securing Kubernetes

, explores the practical (and often perilous) intersection of Generative AI and cluster orchestration. McCune, a veteran KubeCon speaker and a foundational voice in container security, will present the results of his deep-dive research into whether Large Language Models (LLMs) can actually be trusted with the sensitive credentials. Rather than just discussing theory, Rory will aim to demonstrate how LLMs handle specific Kubernetes security tasks, revealing where they provide genuine architectural insight and where they tend to hallucinate dangerous misconfigurations that could leave an organisation exposed.

This talk is a critical reality check for the security community as AI-assisted DevOps moves from a trend to a standard operating procedure. McCune will break down how advanced techniques like improved prompting and 

 reasoning can significantly shift the safety of an LLM's output, while also highlighting the so-called no-go zones where human expertise remains non-negotiable. For security architects and engineers, this session provides a vital framework for auditing AI-generated IaC templates, ensuring that the speed of AI doesn't come at the cost of a catastrophic security breach.

10. Audit-ready Kubernetes: How Chase UK leveraged policy-as-code for continuous compliance

 and co-creator of Kyverno, provide a rare under the hood look at building a cloud platform within the high-stakes world of regulated retail banking. Goyal, who manages the end-to-end Kubernetes ecosystem for Chase UK, will detail how his team transformed a massive compliance undertaking into a streamlined, automated engine. By leveraging Kyverno, OpenReports, and Grafana, they successfully shifted security left, allowing their backend engineers to ship code at speed while maintaining a real-time policy-as-code safety net that satisfies stringent financial regulators.

This talk is a beacon for the security and compliance communities because it addresses the ultimate white whale of enterprise DevOps: reducing audit times from weeks to minutes. Bugwadia’s deep perspective as a Kubernetes 

 co-chair, combined with Goyal’s real-world production perspective from JP Morgan Chase, offers a definitive guide on how to empower security teams to write independent policies without bottlenecking development. For any platform team operating in a regulated sector (or simply running mission-critical workloads) this session provides a proven framework for turning compliance from a manual, fear-driven process into a better, more transparent, and scalable process.

Nigel Douglas

Head of Developer Relations

Catch lightning talks, hands-on demos, and prizes while learning how to secure every artifact in your supply chain.

Join Cloudsmith in Amsterdam at KubeCon Europe 2026

13 KubeCon Europe 2026 sessions not to miss

 LLMOps is the operational framework for managing the lifecycle of Large Language Models (LLMs). Unlike DevOps, which focuses on deterministic code, 

 must handle probabilistic assets like prompts, embeddings, and fine-tuned models. This shift requires a move from standard CI/CD to specialized 

 to ensure system traceability and trust.

 is a specialized set of practices for automating and managing the end-to-end lifecycle of LLM-powered applications. It extends MLOps principles to address the unique requirements of generative AI, specifically focusing on 

, prompt engineering, and vector-based data flows.

While DevOps focuses on application code and MLOps on traditional machine learning models, 

 Managing base models and their task-specific variants.

 Versioning the system instructions that dictate model behavior.

 Curating the "knowledge" used in Retrieval-Augmented Generation (RAG) systems.

 Monitoring outputs that change even when input code remains the same.

In essence, LLMOps is about operationalizing AI rather than just software binaries.

LLMOps vs DevOps: Why the difference matters

 isn't about choosing one over the other; it’s about understanding where 

 begin. DevOps is built for deterministic systems; if you deploy the same code, you get the same result. LLM pipelines are probabilistic, meaning the same "code" (prompt) can yield different outputs.

The core takeaway is that the shift from 

 involves handling much larger, more volatile assets that directly influence the "logic" of the application.

Why artifact management matters in LLMOps

In a traditional app, an artifact is just a compiled file. In AI, 

, teams face a "black box" problem where they cannot explain why a model suddenly began hallucinating or failing.

Effective AI artifact management solves for:

 Re-creating a specific model state using exact dataset snapshots.

 Tracking the lineage of a prompt to meet emerging AI regulations.

 Quickly reverting to a previous "known good" version of a prompt or embedding index.

 Preventing redundant training by reusing existing 

 generates a diverse array of non-code assets across the 

. Understanding these is key to moving beyond simple script-based deployments.

 These include base foundation models (like Llama 3 or GPT-4), fine-tuned adapters (LoRA/QLoRA), and quantized versions for edge deployment.

 Snapshots of training data, evaluation sets (Golden Sets), and synthetic data used for testing.

 Versioned system prompts, few-shot examples, and complex prompt chains that function as the "new source code."

 Vector database snapshots and the specific embedding models (e.g., Ada, BERT) used to generate them.

 Production logs, "LLM-as-a-judge" evaluation scores, and human-in-the-loop feedback.

MLOps vs LLMOps: Where traditional approaches fall short

Many teams assume their existing MLOps stacks can handle LLMs. However, 

 Traditional MLOps tools aren't built to treat a 50-word text string (a prompt) as a deployment-critical artifact. Furthermore, the 

 in LLMOps are much richer, requiring semantic monitoring rather than just simple accuracy metrics.

A common point of confusion is the choice between a 

 are for structured data used in tabular ML.

 (like weights and biases or MLflow) are the "System of Record" for the unstructured models and prompts that define an LLM app.

Managing these assets comes with significant 

challenges of artifact management in LLMOps

, including massive file sizes and the high velocity of prompt changes.

 Store prompts in version-controlled repositories, not hardcoded in your app.

 Use a single source of truth for all models and embeddings to avoid "shadow AI" across teams.

 Ensure every inference result is traceable back to the specific model version, prompt, and dataset used.

, never promote an artifact to production without passing an automated evaluation suite.

FAQ: Frequently asked questions on LLMOps

LLMOps manages probabilistic AI assets like models and prompts, while DevOps manages deterministic code and binaries. LLMOps requires specialized pipelines for evaluation and fine-tuning that don't exist in traditional CI/CD.

Why does artifact management matter in LLMOps?

It ensures that every AI output is traceable and reproducible. Without it, you cannot debug hallucinations, comply with AI audits, or reliably roll back failed updates.

What are the most important LLMOps workflows?

Key workflows include data ingestion for RAG, automated prompt evaluation, model fine-tuning, and continuous monitoring of inference quality.

The future of software is no longer just about code; it’s about 

 As LLMs move from experiments to core infrastructure, the transition from DevOps to LLMOps is inevitable.

 today will be the ones building the most reliable, scalable, and auditable AI systems of tomorrow.

To manage LLMOps at enterprise scale, use Cloudsmith as your single source of truth. Discover how by 

Parul Jhawar

Marketing

LLMOps vs DevOps: What LLMOps means for artifact management

 is rarely just an infrastructure move. For most DevOps and platform teams in 2026, it’s a once-in-a-decade opportunity to rethink tooling, eliminate legacy bottlenecks, and modernize the 

 end-to-end. One of the most overlooked, but highest-impact, areas to revisit during this transition is 

As organizations shift workloads and security controls into the cloud, the limitations of 

 quickly become visible. What once worked in on-premise environments often creates friction, risk, and massive operational overhead in a cloud-native world.

 isn’t just a "lift-and-shift" event. It’s the ideal moment to reassess how you store, secure, and distribute artifacts across modern 

Why legacy artifact repositories struggle during cloud migration

Traditional, self-hosted repositories were designed for static infrastructure and perimeter-based security. Cloud environments invert those assumptions.

During migration, teams commonly encounter:

 Legacy tools often require manual server provisioning or expensive over-capacity planning.

 Managing patches, database tuning, and storage maintenance for your own repository steals focus from your core product.

 When global teams depend on a single on-premise instance, latency sabotages developer velocity.

Keeping a legacy repository while modernizing everything else often results in a "partially modern" stack with legacy risk still embedded in your delivery pipeline.

Cloud migration exposes hidden software supply chain risk

Modern cloud adoption increases velocity, but speed without control amplifies risk across the 

 Cloud-scale builds pull in thousands of external packages that need immediate scanning.

 Difficulty tracking exactly "who built what and where" across fragmented environments.

 Brittle legacy controls that can't handle the dynamic nature of cloud-native deployments.

Re-evaluating artifact management during migration allows teams to embed 

 governance exactly when redesigning their pipelines.

The modernization opportunity: Fully managed artifact repositories

Cloud migration creates the perfect window to replace self-hosted infrastructure with a fully managed

 built for elasticity and global distribution.

 No more storage planning or maintenance; the platform automatically scales with your builds.

 A built-in Package Delivery Network (PDN) delivers artifacts worldwide to reduce latency.

 Features like automated vulnerability scanning and signature verification are baked in, not bolted on.

Instead of recreating legacy architecture in the cloud, organizations can move directly to a fully managed model aligned with cloud‑native principles. This shift transforms artifact management from a maintenance task into a strategic layer of the delivery platform.

When to move: Aligning your migration strategy

Teams often postpone modernization because migration feels complex. However, delaying the decision typically leads to "double migration" work, migrating the legacy tool today and replacing it tomorrow.

Aligning modernization with your cloud move avoids:

 Design your CI/CD for your final destination, not a temporary stop.

 Cloud-native migration scripts (like the Cloudsmith CLI) handle the transfer of binaries and metadata once.

 Ensure your new cloud environment launches with a clean, high-performance foundation from day one.

Signs your artifact management is holding you back

Before moving to the cloud, audit your current state. If these "silent killers" sound familiar, a lift-and-shift solution will only migrate your technical debt:

 Your team spends hours every month on repository upgrades, patching, and storage "garbage collection".

 Global developers or remote build agents face high latency because your on-premise repository lacks a global distribution network.

 You struggle to provide a complete "bill of materials" (SBOM) or audit trail for a security incident.

 Your pipelines rely on custom, "home-grown" scripts to move packages between environments because your tool doesn't support native promotion workflows.

The strategic ROI: What actually changes?

 during a cloud move isn't just a technical swap; it delivers measurable business impact:

 By eliminating manual bottlenecks and enabling faster access to dependencies, teams often see 

 Centralized policy enforcement and automated vulnerability scanning move security from a "final check" to an integrated part of the build.

 removes the "toil" of server management, allowing your DevOps engineers to focus on product innovation rather than infra-maintenance.

 You trade hidden infrastructure costs and administrative salaries for a predictable, transparent, fully managed model.

Evaluating alternatives: Beyond JFrog and Nexus

Cloudsmith Blog

Dependency confusion and trust boundaries in modern builds

13 KubeCon Europe 2026 sessions not to miss

LLMOps vs DevOps: What LLMOps means for artifact management

Why cloud migrations are the best time to re-evaluate your artifact management

LLMs on Kubernetes: same cluster, different threat model

I love Software (in) NI

AI artifacts: The new software supply chain blind spot

Securing LLM dependencies against serialisation attacks

Top 10 most popular LLM models on Hugging Face

Protect your software supply chain from typosquatting with Cloudsmith

Securing AI-generated code with Cloudsmith

From ingredient list to control point: SBOM-based component-level security