Managing software dependencies is one of those things that sounds simple, but gets really, really tricky. Building enterprise software at scale usually means pulling in thousands of open source libraries, container images, models, OS packages, and other binary artifacts, tracing a dependency graph that can go many levels deep. All this software re-use provides huge benefits in terms of efficiency (why write the same code over and over) and security (use battle-tested code). But it also opens up the software supply chain to threat vectors from malicious actors.

Our partner Chainguard provides an essential service in shipping vulnerability-free container images, along with software packages that are safely built from verified sources. Many of our customers rely on Chainguard for this binary content, processed through the Cloudsmith control plane and served over our distribution network.

Of course, not all of Chainguard’s customers use Cloudsmith. To take advantage of a product like Chainguard Libraries, a typical company will need to address at least a few of these requirements, notably the need to blend Chainguard-sourced Javascript libraries with the global set of packages available from the npmjs public registry. At yesterday’s 

, which provides an npm proxy along with the ability to enforce cooldown and license policies. We expect this functionality will open up a new market for Chainguard Libraries among customers who may not yet have a robust artifact management platform in place.

Naturally, we think the combination of Chainguard + Cloudsmith provides an even better experience. Cloudsmith puts Chainguard content into the broader context of an enterprise’s entire software supply chain, including blending Chainguard indexes with upstream public registries (like npm and PyPI), commercial libraries, and locally sourced packages. Cloudsmith adds critical services like upstream caching; a general-purpose policy-as-code engine; comprehensive scanning for vulnerabilities, licenses, and malware; support for 30+ formats beyond Javascript and Python; a high-performance global package delivery network; logs and observability; and much more.

 as an important addition to their build processes. And we agree wholeheartedly with Chainguard that the most practical way to consume Chainguard Libraries is through an artifact management layer. Given the increased pace of software development with the advent of agentic AI development tools, this degree of security and control is essential for securing the software supply chain.

Cloudsmith’s take on Chainguard Repository

 will be the first Kubernetes major release of 2026, and it’s full of really exciting updates for security, AI hardware, and more! As always, removing enhancements with the status of “

” we are seeing 80 enhancements in all listed within the 

Kubernetes 1.36 brings a whole bunch of useful enhancements, including 36 changes tracked as ‘

’ in this Kubernetes release. From these, just 

 are currently graduating to stable, such as 

 enhancements graduating to that GA status.

 features are also listed in the enhancements tracker, one of which introduces the ability to report when a PVC was last used in 

. A simple by powerful use-case where users can now see if a PVC is sitting unused, so in larger clusters this would really help DevOps teams to get rid of any unused and unwanted PVCs.

As always, let’s jump into all of the major graduations, deferred enhancements and deprecations scheduled for Kubernetes 1.36.

Here are a few of the changes that Cloudsmith employees are most excited about in this release:


It’s becoming a regular comment in these recent Kubernetes release notes, but the DRA API is seeing a LOT of exciting enhancements in the 1.36 update. [

 all updated in this release]. This led the Cloudsmith team to add dedicated 

 updates. Anyways, this specific DRA enhancement is exciting because it brings more granularity and automation to hardware management, allowing admins to take specific devices offline for maintenance without disrupting the entire cluster. By introducing taints and tolerations for hardware, similar to what we already have for pod deployments, we can all benefit from automatically rescheduling pods away from failing devices while still letting specialised test pods access them for daily troubleshooting activities.

Nigel Douglas - Head of Developer Relations


I am absolutely thrilled to see OCI image volumes finally hitting Stable status in Kubernetes 1.36 because, as a Product Manager working on the OCI format support at Cloudsmith, I can see this enhancement turning existing container registries into universal artifact hubs. For years, dev teams have been forced into the so-called fat image anti-pattern, where they’re basically bundling massive 

, static assets, and binary plugins directly into their application images, which ultimately creates a nightmare for security patching and bloats deployment times. By graduating this to Stable, we’re now seeing a native, high-performance way to decouple user data from your logic. Devs can now push Hugging Face LLM weights or commercial signatures as independent OCI artifacts and mount them as a 

 just as easily as a ConfigMap. This doesn't just simplify CI/CD pipelines by allowing platform teams to swap content without rebuilding the base engine, but it also drastically shrinks your potential attack surface for the platform teams who are managing these deployments. It’s a massive win for the ecosystem that transforms the OCI registry from a basic storage location for apps into a more dynamic, structured delivery system for any content that a pod needs to succeed.

#5793 Manifest-based Admission Control configuration


As a CSM, I’m genuinely stoked for this 1.36 feature because it finally lets platform teams secure their actual admission control configs. When we think about moving mission-critical policies from the API to static files on the control plane disk, platform teams can now prevent the scary security blindspot where the cluster was vulnerable during the startup. Based on what I'm hearing from the teams I work with, this means vital guardrails (like blocking privileged containers) are now immune to accidental 

 crashes. It’s a massive win for their platform stability, providing platform engineers with a somewhat tamper-proof approach to keeping the 

 secure from the very first second the API server wakes up.

Mutable Container Resources when Job is suspended


This proposal seeks to enhance Kubernetes Batch Job management by relaxing the immutability of a Job’s Pod template while it is in a 

 flag, this change would allow higher-level queue controllers to mutate resource specifications (specifically 

) before a Job is unsuspended and pods are created. By allowing these updates, cluster administrators and automated controllers can dynamically optimise resource allocation based on real-time cluster capacity, current queue priorities, and actual workload utilisation, ensuring that expensive hardware like GPUs is used efficiently.

The design ensures that these mutations are only permitted when a Job is fully suspended and has no active pods, mitigating the risk of disrupting running workloads. While the proposal does not include implementing a specific queue controller or supporting in-place pod updates, it provides the necessary API primitives for external tools (like 

) to perform checkpointing and resizing. This flexibility allows a Job to be suspended, its resource requests lowered to match actual usage, and then resumed, thereby improving overall cluster throughput and reducing resource waste.

Add Recreate Update Strategy to StatefulSet


Starting in Kubernetes 1.36, the introduction of the 

 for StatefulSets addresses a long-standing 

 that has plagued users since 2018. Previously, if a StatefulSet update was triggered with a broken configuration (such as a non-existent Docker image), the controller would wait indefinitely for the failing Pod to become 

 before proceeding. Even if a user reverted the configuration to a known-good state, the StatefulSet would refuse to manage or fix the broken Pod because it was stuck in a validation loop, forcing administrators to manually delete the Pod to unblock the controller.

 strategy (moving to Alpha in this update) provides a more aggressive alternative to the standard RollingUpdate. It allows the StatefulSet controller to prioritise reaching the desired state by terminating existing Pods before creating new ones, effectively bypassing the 

 deadlock. This change transforms what was previously documented as a known issue into a manageable configuration, ensuring that automated CI/CD pipelines and operators can recover from misconfigurations without manual human intervention.

WAS: Integrate Workload APIs with Job controller


The feature represents a major step in Kubernetes' evolution to natively support complex batch and AI/ML workloads. Historically, Kubernetes scheduled individual Pods independently, which caused issues for distributed training jobs that require all participants to start simultaneously (gang scheduling). This feature introduces the 

 object to act as a bridge between high-level controllers (like the Job controller) and the scheduler. By integrating these, the Job controller can now automatically generate a Workload representation of itself, allowing the scheduler to understand the resource requirements and scheduling constraints of the entire group of pods rather than treating them as isolated units.

For the Kubernetes 1.36 Alpha update, the proposal focuses on standardising this integration and refining the API surface. Key changes include introducing the PodGroup as a standalone runtime object and renaming the embedded field within the Workload spec to 

 to ensure a cleaner, more extensible hierarchy. Specifically for the Job controller, the 1.36 update aims to enable the creation of Workload and PodGroup objects by default for 

 Jobs (those where parallelism does not change). This release also seeks to resolve a critical debate on 

, which is whether the release team should maintain separate 

 policies or to unify them into a single parameter where a 

 equal to the total replicas represents strict gang scheduling.

 marked a simple, formal separation of two different KEPs that were previously managed as a single unit: 

 (the Deployment pod replacement policy). The split was justified because the #3973 enhancement which introduced the 

 field to track pods in the process of shutting down moved through the development cycle faster than the more complex pod replacement policy. By decoupling them, the 

 team can now track their graduation through Alpha, Beta, and Stable stages independently, preventing the progress of one from being stalled by the other.

The merged changes include updated documentation and readiness reviews (PRRs for short) for both features. Key technical discussions during the PR focused on ensuring proper version skew policies, specifically requiring that the 

 to avoid status synchronisation issues. While the terminating replicas feature is already seeing implementation in recent releases, the specific API and logic for the pod replacement policy remain in progress, now neatly organised under its own dedicated proposal for future tracking in the 1.36 update.

Graduating to stable, Mutating Admission Policies introduce a declarative, in-process alternative to traditional mutating admission webhooks by leveraging 

. This enhancement allows cluster administrators to define resource modifications (such as injecting sidecar containers, enforcing image pull policies, or setting default labels) directly within Kubernetes using 

 objects. By using CEL's object instantiation alongside 

, the API server can perform these mutations internally, significantly reducing the operational overhead, latency, and webhook fatigue associated with maintaining external infrastructure.

Beyond simplicity, this native approach offers superior performance and reliability. Because the mutations are in-process, the 

 can introspect changes to optimise execution order and safely re-run policies to ensure 

. While it does not aim for 100% feature parity with webhooks, specifically excluding external calls, it covers the vast majority of common use cases while providing a safety field to validate that mutations remain consistent. This move effectively brings the power and efficiency of 

 to the mutation phase, creating a more robust and integrated policy management framework within the Kubernetes ecosystem.

This proposal introduces a mechanism to mitigate 

 in Kubernetes by allowing controllers to detect when their local cache lags behind the API server. Currently, controllers in the 

) rely on eventually consistent watch streams, which can lead to spurious reconciles or incorrect decisions (like scaling or deleting resources) based on outdated data. To solve this, the enhancement proposes an opt-in read-after-write guarantee. By tracking the 

 of objects after a write and updating the 

, controllers can verify if their previous changes have propagated to the local cache before proceeding with the next reconciliation.

In practice, this logic will be integrated into the core processing loops of sensitive controllers, such as the DaemonSet controller. If a controller determines that its cache has not yet caught up to its last-written state, it will 

 the object with exponential backoff rather than performing a potentially erroneous reconcile. This targeted approach ensures consistency for specific resources without imposing a global performance penalty, though it requires careful handling of edge cases like controller restarts and cache resyncs to prevent permanent reconciliation stalls.

Separate kubectl user preferences from cluster configs


 feature introduces a dedicated configuration file (typically located at 

) designed to separate individual user preferences, such as command aliases and default flag settings, from the cluster credentials and server information stored in a standard 

. This separation allows users to maintain consistent local workflows (like enforcing interactive delete confirmations or silencing deprecation warnings) across multiple clusters without modifying shared or auto-generated connection files. The major change moving into 

, whereas it previously required manual activation. To support this promotion, the update introduces the 

 management command to help users programmatically view and edit their preferences, and it formalises security controls through a 

 to prevent the execution of untrusted binaries.

This relaxed ServiceName validation feature is an improvement designed to bring the naming constraints of Service resources into alignment with other standard Kubernetes objects. Historically, Services were restricted by a stricter 

), which prohibited names from starting with a numeric digit. This update transitions the validation to the more flexible 

 standard, finally allowing users to create Services with names like 

, the feature is moving from an opt-in experimental state to being 

. This graduation signifies that the community has successfully completed compatibility testing with downstream systems like DNS providers and Ingress controllers, and has verified that the change remains safe during cluster upgrades and downgrades by maintaining immutability checks on existing resource names.

Extend PodResources to include resources from DRA


 to bridge the visibility gap between the Kubernetes node and external monitoring tools. Historically, this API only allowed monitoring agents to see which CPUs or standard devices were assigned to a container. This feature extends that capability to include resources managed by the evolving DRA feature. By adding a 

 method for targeted pod queries, the Kubelet can now report specific DRA-allocated hardware (such as GPUs or FPGAs) directly to monitoring stacks like 

. To ensure this data remains available even if a DRA driver goes offline, the system implements a checkpointing mechanism within the 

, guaranteeing that resource assignments are preserved across Kubelet restarts.

The primary benefit of this enhancement is 

granular observability for next-gen hardware

. Platform operators can now access per-pod metrics for DRA-managed resources, which is essential for accurate billing, performance tuning, and troubleshooting in AI/ML workloads. Since the feature is graduating to Stable in v1.36, the community can expect full production-ready reliability with a guaranteed 

 requests over a rolling 5-minute window as well as low-latency response times (P99 < 100ms). The graduation to GA means the 

, allowing third-party ecosystem tools to officially rely on stable gRPC fields without the risk of breaking changes or experimental instability.

This is a security-focused refinement of how Kubernetes handles network addressing, specifically targeting the stricter validation of 

 across the API. Historically, Kubernetes relied on older Go functions that were overly permissive, allowing ambiguous formats like IPv4 addresses with leading zeros (for example: 

), which different systems might interpret differently (octal vs. decimal), potentially leading to security vulnerabilities like 

. For platform teams, this is highly beneficial because it eliminates many IP address risks and ensures consistency between Kubernetes and underlying network plugins (Calico and Cilium) and OS-level libraries. To maintain stability, the plan uses 

, which prevents new invalid entries without breaking existing workloads, which means that teams can update a service’s labels without being forced to immediately fix a legacy IP field. This move toward canonical formats (like standardised IPv6 strings) simplifies long-term maintenance, auditing, and observability, as platform engineers can now trust that network data is unambiguous and follows a single source of truth format across the entire cluster.

API for external signing of Service Account tokens


This KEP proposes a transition from static, file-based Service Account key management to a more dynamic integration with external providers like 

 loads signing keys from the local disk at startup, a method that lacks flexibility and poses a security risk, as any user with filesystem access could exfiltrate the signing material. By introducing a new 

) accessible via a Unix domain socket, Kubernetes can delegate JWT signing and public key retrieval to an external plugin. This shift enables seamless key rotation without requiring an API server restart and ensures that sensitive private keys never reside in the cluster’s local memory or storage.

To maintain consistency and security, the 

 remains responsible for assembling the JWT claims and headers, while the external signer only provides the signature. This architecture prevents claim divergence and ensures that externally signed tokens remain compatible with existing OIDC discovery endpoints. While the proposal introduces a new 

 flag, it preserves backward compatibility by keeping existing file-based flags as mutually exclusive options. Potential performance overhead from socket communication will be mitigated through benchmarking, and access to the signing socket will be restricted via standard Unix file permissions to prevent unauthorised token generation.

Kubernetes 1.36 introduces a brand-new conditional authorisation capability, which is a framework that allows authorisation decisions to depend on the actual data within a resource (like specific fields or labels) rather than just its metadata. Currently, Kubernetes authorisers (like 

) are basically blind to the content of a request body. This KEP bridges that gap by using a two-phase evaluation process. 

In the first phase, the authoriser performs 

 response containing a set of requirements (for example, " only Allow if 

In the second phase, these conditions are enforced during the 

 stage, where the API server finally decodes the object and has access to the necessary field data to make a concrete decision.

This architecture solves several long-standing limitations by providing a unified, cohesive policy model that spans both authorisation and admission. It eliminates the need for administrators to essentially over-grant their permissions in RBAC only to restrict them later with separate tools like 

By propagating conditions through the request chain, the system ensures atomicity (the decision is based on a single snapshot of policy) and improves user experience, as users can see exactly why they are restricted via 

 lookups. Concretely, the enhancement extends the 

 API, enabling both in-tree and out-of-tree authorisers to implement fine-grained controls, like restricting which fields user can update or which 

 a CSR can use without compromising API server's performance or security.

Constrained impersonation helps Kubernetes move away from the unrestricted legacy model where an impersonator automatically inherits all permissions of the target user. To mitigate these security risks (especially for controllers and per-node agents) impersonators must now possess two distinct sets of permissions: 

The authority to impersonate a specific identity (

Right to perform specific actions on behalf of that identity (

This opt-in mechanism ensures that even if a controller is compromised, its impersonation power is limited to specific resources and verbs. In the below 

 example, a controller can be restricted to impersonating only the specific node it is running on by using the downward API to identify itself and configuring the client as follows:

By introducing these prefixed verbs like 

, platform engineers can now define highly specific RBAC roles. This setup ensures that an impersonator can only execute a request if both the impersonator has the 

 permission for the action and the impersonated principal has the underlying permission to perform the task itself.

Kubernetes 1.36 is addressing a long-standing recovery gap where encrypted API resources become undeletable due to missing keys or data corruption. Currently, if a single object in 

 fails to decrypt or decode, listing that resource type fails entirely, forcing admins to bypass the Kubernetes API and manually manipulate the database, which is a really risky and complex process. To solve this, the proposal introduces a way to identify these broken resources and provides a new 

 that allows for their removal even when their content remains unreadable.

However, this unconditional delete is a high-risk operation. Since the system cannot read the object's metadata, deleting it bypasses standard safety features like finalisers and 

, potentially leaving orphaned system processes (like running Pods) behind. To mitigate this, the design includes a new 

 for better diagnostics and requires explicit confirmation through 

 prompts and server-side admission layers to ensure administrators understand the impact before purging malformed data.

This enhancement introduces support for user namespaces, a critical isolation feature that maps containerised user and group IDs to different, unprivileged IDs on the host. By allowing a process to hold root privileges within a pod while remaining unprivileged on the underlying node, the KEP significantly bolsters node-to-pod and pod-to-pod isolation. This ensures that even if a process achieves a container breakout or possesses elevated capabilities like 

, its impact is strictly confined to the namespace, preventing it from exercising administrative control over the host or other pods.

The implementation specifically addresses and mitigates several high-severity vulnerabilities where container escapes or privilege escalations previously threatened host integrity. Key CVEs resolved or dampened by this update include:

Kubernetes 1.36 – What you need to know

The software supply chain is more complex than ever. Open source, containers, and now AI models form a growing and complex web of package dependencies that power software development. Developers have a lot of options and flexibility when building software, but this convenience also comes with risk. More dependencies expand the attack surface of a build and create long remediation cycles.

Vulnerabilities often emerge after something is already in production. Efficient remediation requires a strategy that balances two critical needs: intelligence and control. Your ability to maintain applications and reduce the impact of vulnerabilities requires you to 1. know what to do, and 2. have the right tools to do it.

Let’s look at a strategy that helps engineering teams build, secure, and ship software faster and more safely. We’ll see how Endor Labs provides the intelligence and Cloudsmith provides the point of control to efficiently remediate software vulnerabilities.

It’s not enough to simply know that vulnerabilities exist. You need to understand the different ways to remediate those vulnerabilities and the impact those fix options may have. Endor Labs provides the deep analysis required to understand what is actually happening inside your code.

: It builds a complete graph of your software, including source code, dependencies, and container images.

: Rather than just listing vulnerabilities, it uses 150+ risk signals, like maintainer activity and security practices, to help you decide which components to trust.

: It identifies which vulnerabilities are truly reachable at the function level, allowing teams to ignore the ‘noise’ and focus only on risks that can actually be exploited.

: Another layer of technical decision-making, this lets developers see the downstream impact of each upgrade option, anticipate breaking changes, and plan accordingly.

Once you identify your preferred fix with Endor Labs, you can use Cloudsmith as a ‘point of control’ and the single source of truth for your software artifacts.

: It provides the system of record to curate, proxy, and inspect every package and container your developers use.

Cloudsmith scans packages when they first enter the platform by default. 

 let developers establish clear guardrails around package management. Built on industry-standard Open Policy Agent (

) and using its declarative language Rego, policy management from Cloudsmith provides policy-as-code flexibility and scalability within your Cloudsmith repositories. Cloudsmith 

 on vulnerabilities to quickly identify new threats and emerging risks to the artifacts in your repository.

: It caches and secures every dependency, protecting your builds from public registry outages and ensuring every developer works with the same verified tools.

The overarching strategy is as follows: Endor Labs analyzes your codebase, identifying what vulnerabilities exist, the potential impact remediation will have, and where in your source code to address them. When implementing updates to fix those vulnerabilities, Cloudsmith provides a centralized and governed environment of managed artifacts, ensuring secure and consistent build processes across your entire organization.

The emerging AI software supply chain introduces even more complexity and potential conflicts and vulnerabilities to the software development lifecycle. But pairing Cloudsmith and Endor Labs extends to this area of development, too. They bring the same principles of open-source governance to the rapidly evolving world of AI models, MCP servers, and other AI dependencies.

, which brings standard software supply chain governance to AI/ML workflows. Proxy and host AI artifacts, like Hugging Face models and other ML package formats, just like you would with non-AI artifacts. Managing your AI/ML models alongside your code helps to eliminate blind spots and ensure consistent security and access controls across your environment.

Endor Labs applies governance and security controls to the code that integrates these AI/ML models. It gives you visibility into model provenance and risk factors that you can enforce with organizational policies. This includes the ability to report AI components in your SBOM.

Close the loop on software supply chain security

Cloudsmith ensures you consume secure and policy-compliant artifacts at the registry level, while Endor Labs provides deep code analysis, risk prioritization, and remediation workflows. Together, they keep applications and development teams working efficiently by reducing vulnerability noise, eliminating exploitable risks faster, and letting engineering teams focus on building quickly without sacrificing security.

With Cloudsmith and Endor Labs, security is built into every artifact your team consumes and every line of code you ship.

Intelligence and governance in the software supply chain with Endor Labs and Cloudsmith

 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 

Cloudsmith Blog

The 2026 guide to software supply chain security: From static SBOMs to agentic governance

Axios NPM distribution compromised: What happened and how to prevent malicious packages from reaching your builds

Layered defense for dependencies: Why dependabot needs an upstream gatekeeper

How Cloudsmith can protect against the LiteLLM attack

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

How to achieve DORA compliance: The complete checklist for financial institutions

Securing LLM dependencies against serialisation attacks

Top 10 most popular LLM models on Hugging Face

7 key metrics to measure software supply chain security

Cloudsmith’s take on Chainguard Repository

Kubernetes 1.36 – What you need to know

Intelligence and governance in the software supply chain with Endor Labs and Cloudsmith

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