By submitting this form, you agree to our 

Answer twenty questions about your artifact and supply chain practices. Get a custom report card showing your maturity score against key regulatory and compliance frameworks.

Artifact Security Maturity Assessment

Cloudsmith now supports hosting public and private Nix binary caches. Teams that use Nix and NixOS can point existing 

 workflows at Cloudsmith without any additional tooling.

(Note: Nix format support is currently in Early Access.)

Nix builds work differently from most package ecosystems. Initiating a build in Nix begins with an evaluation of all the inputs that go into the build. This includes source code, dependencies, and build instructions, and each item gets hashed. The evaluation output is a derivation (a 

 file), which is a build recipe that describes what’s in the build. Nix then hashes the derivation to compute the package’s store path. Because downloading a pre-built version is faster than building from source, Nix then asks its substituters (remote binary caches like the default 

) whether that store path already exists. If it does and is signed by a key that Nix trusts, then Nix will download it. If it doesn’t exist, Nix builds it from scratch.

 packages from the public cache, but their own builds require a private binary cache, which is typically self-hosted. Relying on the public cache means accepting availability and bandwidth limits, which may not meet the needs of compliance-focused teams. Self-hosting a private cache with 

 or S3 means patching, scaling, and on-call duty for infrastructure that only serves packages.

 for Nix release channels. You must configure a separate upstream for each channel you want to use.

The first time you request a store path that Cloudsmith doesn’t have, it fetches the package from the configured NixOS channel, caches it, and serves it. Subsequent pulls are served from Cloudsmith’s cache, so builds are fast and keep working during a 

You can also push new Nix builds to a Cloudsmith repo, which then functions as a private Nix binary cache, but without the overhead tax of self-hosting.

Signing and verifying Nix packages in Cloudsmith

Where other ecosystems use package name and version number to identify packages, Nix uses a cryptographic hash to identify and verify them. Cloudsmith signs each package’s 

 with the repository’s ED25519 key on every read, and Nix verifies that signature against trusted keys. Because signing happens on every read rather than once at upload, key rotation takes effect immediately, with no backlog of packages to re-sign, and multiple keys can be active and signing simultaneously.

To get started using Nix with Cloudsmith, you can create a dedicated Nix repository. Add that repo to your Nix 

 list, and the repository’s public key to 

. This configuration means Nix treats Cloudsmith like cache.nixos.org. To proxy a public channel, add that as an upstream to the repo.

For private repos, authenticate with an entitlement token in a 

 file. Push Nix packages you build locally to your Cloudsmith Nix repo using 

 flag because locally built packages are unsigned and Cloudsmith handles signing on read.

For detailed setup instructions, see our 

Cloudsmith allows you to consolidate cached Nix packages in a single, cloud-native environment with multi-format repositories. Teams no longer rely on public cache availability, or pay the operational tax of self-hosting. Upstreams cache public channel packages in Cloudsmith for fast, reliable pulls.

Nix packages often sit outside the access controls and audit logging that cover the rest of your software supply chain. Bringing Nix into a Cloudsmith workspace, with 30+ formats in multi-format repositories, lets you govern Nix packages with the same access controls, entitlement tokens, and audit logs that you use on the rest of your software supply chain.

 for more information about using Nix in Cloudsmith.

Jason Myers

Technical Content Marketer

Cloudsmith expands support to Nix

With legacy artifact managers, every ecosystem that dev teams use requires a separate repo. What happens when teams try to keep their line of work isolated, but they rely on the same ecosystem and packages as other teams? Platform teams have to configure multiple instances of the same repo for each team. This increases the complexity of the organizational repo structure, and means more repos, URLs, configs, and security policies to manage, not to mention greater storage needs. Using Cloudsmith’s 

 you can configure multiple upstreams in a multi-format repo, cache those packages once, and deliver them to downstream repos, all with a single URL.

Maintaining upstreams for every individual repository comes with an overhead tax. The amount of effort teams have to put into maintaining upstreams can quickly become a burden depending on how they structure their repositories. Legacy artifact managers rely on language-specific repos so teams need to configure an upstream for each repo. Therefore, if you use npm, Python, Rust, and Maven, then each language has its own upstream URL, configuration, and security policy. Now, if you’re working on a small team and those are the 

 repositories you pull from, it's manageable. But at scale, going from four repos to 40+, things get much more complex.

While maintaining dozens or hundreds of repos is a very real burden, it's the toll all those endpoints take on your security at scale that's easy to overlook.. The need to configure security policy for each individual upstream simultaneously increases the attack surface and the number of gaps within that attack surface. Policy enforcement becomes inconsistent and hard to do across enterprise-scale upstream configurations. A single enforcement point decreases risk by removing many of the gaps within the attack surface.

Connected repositories are a native Cloudsmith feature that links repositories and resolves packages through a single URL. The images below illustrate two different architectural configurations of connected repositories.

Cloudsmith supports multi-format repositories, so users can configure a single repository with multiple upstreams, as seen in configuration B. The OSS Packages Repository has upstreams for Maven, Python, and NuGet, and this is where packages from those ecosystems get cached. The repository, which is where end users pull from, doesn’t perform any caching or duplication of packages in the OSS Packages repo; it inherits the upstreams from the OSS repo and pulls packages straight through. When configuring connected repositories, teams can set priorities for each upstream (see config B). If two upstreams have the same priority, Cloudsmith automatically breaks these ties based on the upstream creation timestamp.

Package resolution is also automatic for connected repositories. You can see in configuration B above that the Enterprise Packages Repository is PRIORITY 1, the Shared Packages Repository is PRIORITY 2, and the OSS Packages Repository is PRIORITY 3 for the main repository. Cloudsmith resolves packages inside Cloudsmith in priority order first, then resolves packages outside Cloudsmith in priority order. Going back to the diagram, any packages in the main repository get resolved first, followed by packages in the Enterprise Packages Repository, then packages in the Shared Packages Repository, and finally packages in OSS Packages Repository. Each of the upstreams in the OSS repo will have a priority status, so those will resolve according to their established priority.

Connected repositories can reduce upstream sprawl and provide teams with more flexibility in how they structure their repos within their artifact manager. The repo architecture that’s right for your team will depend on what factors you value. Typically the key tradeoffs come down to isolation, visibility, access controls, and operational overhead. (If you want a detailed breakdown of the architecture configurations below, our team can 

 This configuration is exactly what it sounds like. A single repo for every package. While this is structurally simple to set up and run, there is no isolation between lines of work or development environments. This approach works for small teams, but quickly becomes unwieldy for larger teams.

 This approach creates one repo for every language or format a team uses. This is a familiar repo structure used by legacy artifact managers. It offers a single source of truth for each development language and keeping a format-specific approach can make migrating to a new artifact manager easier. However, this structure lacks combined visibility across formats for usage, licenses, vulnerabilities, logs, etc.

 This structure has a repo for each team, service, or product. The line of work approach allows teams to own their repos, which means they can set up granular access controls, giving them more accountability over the trust decisions in their development environment. As for tradeoffs, this structure has higher potential to house duplicate packages and to create sprawl, especially if the repos don’t support multiple formats. Teams need strict tagging discipline when using this approach. For example, poor tagging could lead to deleting packages needed for production

This approach includes one repo for each different production environment, typically build, test, and production. Environment-scoped RBAC and retention rules help to avoid some of the challenges with the line of work approach. This structure also provides a really clean promotion pathway; teams can clearly tell which development stage a package in is based on the repo storing it. The tradeoff is that teams have less visibility into specific lines of work, and need to make sure they follow clear naming conventions to avoid package conflicts.

 This approach combines the line of work and environment-based structures. It consists of one repo for each line of work within each environment-based repo. While it combines the best aspects of those two approaches, it also introduces the potential for repo sprawl, depending on how many lines of work a company has. This structure also requires advanced package promotion logic to ensure the right packages get promoted to the right location. Sharing packages across lines of work can also be challenging, depending on how teams configure their repos.

Connected repositories give you flexibility. The flexibility to pick a repo structure that fits the needs of your organization and the way your teams want to work. You get the flexibility of optimizing your repo structure to accentuate the tradeoffs you want over the ones forced on you from inherited systems. Connected repositories can reduce the URL- and upstream-sprawl that resulted from choosing anything other than a super-repo.

Ready to optimize your repo architecture? 

Simplify repository structure with connected repositories

 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

 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.

A Standardized Approach to SBOM

More articles

Cloudsmith expands support to Nix

Simplify repository structure with connected repositories

Dependency confusion and trust boundaries in modern builds

LLMOps vs DevOps: What LLMOps means for artifact management

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

AI artifacts: The new software supply chain blind spot