 that most developers in the AI space saw within hours: a simple 

 exfiltrated SSH keys, cloud credentials, Kubernetes secrets, API keys, crypto wallets, and more from any machine that ran it. He called it “software horror.” Given the scale, LiteLLM has 

The good news: this attack is exactly the kind of thing a well-configured artifact management setup is built to stop.

LiteLLM is an open-source Python library that acts as a universal API gateway for large language models. Instead of writing separate integration code for OpenAI, Anthropic, Google, and dozens of other providers, developers use LiteLLM to call all of them through a single standardized interface. It's a natural fit for any team building AI-powered applications, which is why it's become something close to infrastructure, with close to 100 million downloads per month.

That position in the AI stack, sitting between applications and every LLM provider, is also what made it an attractive target. A package with that kind of access to API keys and environment variables is worth compromising.

The threat group behind this, known as TeamPCP, didn't find a bug in LiteLLM's code. They worked their way up the supply chain: first compromising Trivy, a widely used open-source security scanner (

), then using that foothold to steal LiteLLM's PyPI publishing credentials. With those credentials, they uploaded two backdoored versions of LiteLLM directly to PyPI. This required no pull request, no code review, and nothing to inspect.

Standard integrity checks passed. The packages were published using legitimate credentials, so there was no hash mismatch, no suspicious metadata, no misspelled package name. The malicious versions were live for roughly three hours before PyPI quarantined them.

Three hours is a narrow window, but it's wide enough. And as Karpathy noted, the attack was only discovered because a bug in the malware crashed a researcher's machine.

The more unsettling detail is how far the blast radius extends. The contagion spreads to any project that depends on LiteLLM. This includes teams using it directly and anyone running 

 or any other package with LiteLLM in its dependency tree. Most developers have no visibility into what their dependencies depend on, let alone controls over it.

Three moments where this attack could have been stopped

The LiteLLM attack didn't require beating sophisticated defenses. It required developers pulling packages directly from a public registry with no organizational governance layer in between.

That's the gap Cloudsmith closes. It makes sure that your team doesn’t pull directly from PyPi without a policy check first.

Here's how that works in practice, mapped to the specific failure modes in this attack.

Cloudsmith acts as a proxy between your developers and upstream registries like PyPI. Packages don't arrive on developer machines directly from PyPI, they pass through Cloudsmith first, where your organization's policies apply. This one change puts every subsequent control within reach.

Apply a quarantine window to new package versions.

Cloudsmith lets you configure a cooldown policy that holds newly released versions in quarantine before they enter your environment and get served to your team. This gives the security community time to identify problems before your developers install anything. The policy applies organization-wide; it doesn't depend on individual developers remembering to check a release date or configuring pip correctly. The three-hour window that defined the LiteLLM attack becomes irrelevant if new versions don't reach your developers for 7 to 14 days.

Even on disciplined teams, a developer working quickly on their laptop might pull directly from PyPI. That's why your CI/CD pipelines should point to Cloudsmith independently of workstation configuration. Code that pulls a bad version locally doesn't survive the build pipeline because it gets caught before it reaches staging, production, or any shared infrastructure.

The LiteLLM attack is a useful reminder that AI tooling is software, and software has a supply chain. As AI agents take on more autonomous roles in development – installing dependencies, running builds, pulling packages – the same governance principles apply whether the consumer is a human or an agent. Controlling what packages enter your environment is part of running AI infrastructure responsibly.

If you'd like to understand your current exposure, 

 with Cloudsmith for a custom assessment of your software supply chain.

How Cloudsmith can protect against the LiteLLM attack

Software supply chains are complex and increasingly fragile. For enterprise teams, managing an ecosystem of open-source packages, container images, and AI/ML models is no longer just a storage problem, it is a delivery and governance challenge.

Cloudsmith processes petabytes of artifact data every month for global enterprises. To meet these demands, we didn't just move our platform to the cloud. We built a genuinely cloud-native platform from day zero, using AWS to ensure that every artifact is fast, available, and trustworthy.

The architecture of trust: Why cloud-native matters

Many legacy artifact management tools were designed for a different era. Cloud-hosted is different from cloud-native. Cloud-hosted solutions typically begin as on-premise software that vendors retrofit to run on cloud servers. This architecture doesn’t eliminate operational maintenance; it shifts it from managing physical hardware to managing patching, upgrading, and complex high-availability configurations.

Cloudsmith is different. By building natively on AWS, we provide a platform that abstracts away infrastructure headaches.

: We handle all updates, patches, and scaling. Teams can stop firefighting infrastructure incidents and focus on shipping value.

: Our system uses multi-region redundancy by default. There is no single point of failure, ensuring that builds don't stall even if a specific region or load balancer goes down.

: AWS allows us to scale horizontally and vertically. Whether you are running ten builds or ten thousand, the platform maintains consistent performance without manual tuning.

That elasticity matters beyond traditional binary packages, too. As AI/ML models become standard supply chain assets, the architecture has to handle their size (often measured in gigabytes) without a separate delivery strategy.

Performance at the edge: Global delivery without the latency

With AWS, Cloudsmith takes advantage of what the cloud makes possible: elastic compute, global reach, and the ability to serve large enterprise customers without the operational overhead of managing infrastructure.

The edge is where that global reach becomes tangible for our customers. These are the AWS services we use to deliver global performance and reliability.

 is the backbone of how we distribute artifacts. With over 600 points of presence worldwide, CloudFront allows us to serve packages from as close to the requester as possible. Whether a developer pulls a dependency from their local machine or an automated build system fetches a container image at 2am, an edge location near them serves the request. That proximity is what makes the performance difference our customers depend on.

 extend that further. Authentication and intelligent routing are not afterthoughts in Cloudsmith; they're core to how the platform works. Cloudsmith needs to authenticate and correctly route every incoming request before serving the artifact. CloudFront edge functions enable that logic to run at the edge itself, not at a central registry on the other side of the world. The processing happens where the request is. The result is that every millisecond we would otherwise spend routing back to origin is recovered at the edge, and across the volume of requests we handle – tens of millions per day – those milliseconds add up to faster and more reliable builds for customers.

protects the perimeter of the Cloudsmith platform. While the software supply chain is a high-value target for malicious actors, WAF allows us to block common web exploits and automated bots before they ever reach our API. By leveraging AWS Managed Rules, we ensure our defenses are updated in real-time against emerging threats. This allows us to maintain a high-availability environment where the platform remains performant and accessible only to legitimate users, ensuring the infrastructure behind your artifacts is as secure as the artifacts themselves.

Together, these three AWS services give Cloudsmith the global reach, edge processing capability, and security posture to serve enterprise customers at scale – reliably, and with the performance they need.

AWS EDGE Innovation Spotlight: Cloudsmith | Amazon Web Services

Catch the full conversation: VP of Engineering Ronan O'Dulaing sat down with AWS to discuss how Cloudsmith uses AWS to power its cloud-native artifact management platform. 

A specialized control plane vs. basic registries

Cloud providers offer their own basic artifact registries, but they focus on identity and access management rather than comprehensive supply chain governance.

Cloudsmith provides a unified control plane that goes beyond simple storage. Unlike basic registries or package managers embedded in developer platforms, Cloudsmith delivers:

: We support 30+ package formats, including AI/ML models, in a single repository.

: Using our policy management capabilities (built on OPA), organizations define precise compliance rules. You decide what artifacts are untrusted or non-compliant and block them before they ever enter your environment.

: We don't just scan your artifacts. We continuously enrich packages with new vulnerability and malware intelligence data, ensuring your software supply chain remains protected as new threats emerge.

AI has changed the requirements for artifact management. ML models are significantly larger than traditional software packages, often reaching multi-gigabyte sizes.

Our AWS-backed architecture allows us to adapt. We parallelize metadata fetching and artifact pulls to ensure reliable delivery of massive models. Because we leverage AWS's global reach, these large files still benefit from the same low-latency edge delivery as a standard Python package.

Delivering revenue-critical software with confidence

Reliability and performance are the baseline expectations for modern software delivery. By building a genuinely cloud-native platform on AWS, Cloudsmith ensures that your delivery pipelines are predictable, resilient, and secure.

You don't have to manage clusters, configure regions, or worry about manual replication. You simply get a fast, governed, and reliable software supply chain–globally, and at scale.

See how Cloudsmith handles your specific tech stack. 

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

Yes. DORA became fully applicable on January 17, 2025. By 2026, the grace period for initial Register of Information (RoI) submissions has passed.

Is DORA already in effect?

Threat-Led Penetration Testing (TLPT) is a high-intensity "red team" exercise using the TIBER-EU framework. It is mandatory every three years for systemically important financial institutions.

What is TLPT under DORA?

NCAs can impose periodic penalty payments of up to 1% of the average daily worldwide turnover for the preceding business year.

What are the penalties for non-compliance?

While "SBOM" isn't explicitly named, the requirements in Articles 8 and 30 for asset inventory and supply chain visibility make a software bill of materials the most practical way to achieve compliance.

Does DORA require an SBOM?

Common DORA compliance questions (FAQs)

Digital Operational Resilience Act (DORA) compliance is mandatory as of January 17, 2025. For 2026, the focus shifts from initial implementation to 

. Financial entities must maintain a risk management framework, report major incidents within 24 hours, conduct annual resilience testing, and manage third-party risk via a formal Register of Information (RoI).

, commonly known as DORA, is a landmark EU regulation designed to strengthen the IT security of financial entities. Unlike previous guidelines, which were fragmented across sectors and countries, DORA provides a single, harmonized rulebook for digital resilience.

Its primary goal is to ensure that the European financial sector remains resilient in the face of severe operational disruptions, such as cyberattacks, system failures, or third-party outages.

DORA applies to over 22,000 entities across the EU and their global ICT providers, including the following:

 Banks, credit institutions, and payment providers.

 Investment firms, insurance undertakings, and intermediaries.

 Crypto-asset service providers and crowdfunding platforms.

 Critical ICT third-party providers (including cloud service providers and software vendors) who serve the financial sector.

Why DORA compliance is the 2026 "North Star" for financial risk

DORA is no longer a "future project". We are now over a year into the enforcement era. EU competent authorities (NCAs) are actively auditing implementations, specifically looking for evidence of 

DORA establishes uniform, enforceable resilience standards across 22,000+ entities, including banks, insurers, crypto-asset providers, and their critical ICT third-party providers. If you operate or serve clients in the EU, DORA is your primary regulatory hurdle.

The DORA compliance checklist: The five pillars of resilience

DORA organizes its requirements into five distinct pillars. Use the checklists below to audit your current posture against the specific Articles and Regulatory Technical Standards (RTS).

Pillar 1: How to build a DORA-compliant ICT risk framework (Articles 5-16)

Board-level accountability is the cornerstone of Pillar 1. Article 5 dictates that the management body, not just the CISO, owns the risk.

 Management has approved and actively oversees the ICT risk framework.

 A continuously updated register of all hardware, software, and services, classified by criticality.

 Network segmentation, identity management, and rapid patch cycles are documented and enforced.

 An ICT disaster recovery plan exists with defined RTOs/RPOs, tested and updated within the last 12 months.

 Backup procedures are isolated from primary production environments to prevent ransomware lateral movement.

Pillar 2: Managing ICT incident reporting timelines (Articles 17–23)

In 2026, "major" incidents require a strict three-stage reporting cadence to your National Competent Authority (NCA):

 Within 4 hours of classification (max 24 hours from detection).

 Incident management tools are configured with DORA RTS criteria (client impact, data loss, geographic spread).

 Workflows trigger immediate alerts to the legal and compliance teams when "Major" thresholds are hit.

 All incidents (even minor ones) are logged in an auditable record for year-end trend analysis.

Pillar 3: Executing digital operational resilience testing (Articles 24–27)

Standard pentesting is no longer sufficient for systemically important institutions (G-SIIs, O-SIIs, etc.).

 All critical ICT systems undergo vulnerability assessments at least once a year.

 certified test is scheduled every 3 years.

 Open-source packages and container images are scanned for CVEs before they reach production.

Pillar 4: Mitigating ICT third-party risk (Articles 28–44)

This is the most common area for audit findings in 2026. Article 28 requires a 

 of all third-party ICT arrangements in a specific EBA-compliant format.

 A full register of ICT vendors exists and has been submitted to the NCA via the 2026 reporting portals.

 All vendor contracts include mandatory provisions on data locations, audit rights, and exit strategies.

 Compliance extends to "material subcontractors" (the fourth party) providing critical functions.

Software Bill of Materials implementation:

 A SBOM (SPDX or CycloneDX) is generated for all proprietary and third-party software.

Pillar 5: Voluntary information and intelligence sharing (Articles 45–49)

While Article 45 is voluntary, regulators view active participation in 

 (ISACs) as a sign of high operational maturity.

 The organization participates in a sector-specific threat-sharing community.

 Threat indicators received from external partners are automatically ingested into SOC workflows.

The "Invisible" gap: Software supply chain provenance

 Every open-source package or container image pulled from a public registry is a "third-party ICT dependency." Under Articles 8 and 30, you must know what is in your software and prove its integrity. This is where 

, knowing exactly where code came from and who touched it, becomes a regulatory requirement.

Cloudsmith provides a specialized, cloud-native 

 that serves as the foundation for software supply chain security and DORA alignment. By acting as a centralized "source of truth", Cloudsmith enables financial institutions to move away from fragmented, manual processes toward a unified DevSecOps environment where compliance is baked into the development lifecycle.

The platform ensures continuous identification, tracking, and management of every software component, whether proprietary code or a third-party open-source dependency. Through automated, configurable policy gates, Cloudsmith enables organizations to define strict quarantine rules that align with DORA’s risk-reduction intent, effectively blocking vulnerable or malicious packages before they ever enter the build environment. This proactive stance on 

 directly supports the ICT asset inventory requirements of Article 8 and the testing obligations of Article 25.

Furthermore, Cloudsmith simplifies one of DORA’s most challenging documentation hurdles: the SBOM. The platform automates 

 in industry-standard formats such as CycloneDX, providing security and compliance teams with a granular, real-time inventory of what is slated for production. Because every action within the platform is captured in an immutable, exportable audit log, Cloudsmith transforms compliance from a stressful manual scramble into a simple, on-demand report for regulators. By breaking down the silos between 

, security, and risk teams, Cloudsmith ensures that digital operational resilience is a continuous, automated state rather than a point-in-time exercise.

DORA is a continuous operational commitment, not a one-time project. The checklist above gives you a structured view of every pillar, but the harder work is keeping those controls current: live asset inventories, continuous supply chain scanning, SBOMs for every release, and audit trails that hold up under scrutiny. That's where the right tooling makes the real difference.

If you want to see how Cloudsmith fits your DORA program, 

 with us. We'll map your current software supply chain controls against the specific articles you're responsible for and show you exactly where the gaps are.

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

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 link 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 

Cloudsmith Blog

The AI speed trap: Securing the future of software supply chains

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

Stardrop: New cross-industry npm campaign

Cloudsmith in your IDE: Package intelligence, security remediation, and Infrastructure as Code inside your editor

Layered defense for dependencies: Why dependabot needs an upstream gatekeeper

Closing the enforcement gap: Why visibility isn’t enough for supply chain security

The AI speed trap: Securing the future of software supply chains

Securing LLM dependencies against serialisation attacks

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

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