Cloudsmith provides a control plane at the registry layer, enforcing policies against any ingested artifact to bolster your security posture. Here, we dig into the mechanics of the specific Cloudsmith capabilities that make enforcement at the registry work, and what makes each one meaningfully different from what you can do with a CI gate or a standalone scanner.

Policy management: Write policy against a breadth of risk signals

 is built on Open Policy Agent (OPA) and uses Rego as its written language. In Cloudsmith, the power of policy management comes from what you can write policy against.

Other enforcement approaches often rely on blunt, binary policies. This lack of granularity can result in blocking approved packages, which creates noise and disrupts developer workflows. For example, a binary control may block a package with a CVE score that exceeds a threshold. But CVE is only one of many potential threat signals. CVE severity tells you how bad a vulnerability 

 be. It doesn’t say anything about the likelihood of exploitability. Policy management lets you combine severity with EPSS scores. A package with a critical CVE with a 0.1% EPSS score and a package with a medium CVE currently being actively exploited are not equivalent risks, and your policies don't have to treat them as if they are.

Beyond vulnerability data, policies can evaluate against license type, upstream publish date, package age, custom metadata, and, for Docker images, SBOM contents. That constitutes a much broader range of signals for security teams to use when deciding whether a dependency belongs in their environment. Cloudsmith makes all that data available as policy inputs.

To aid with set-up, provide pre-configured policy templates covering the most common enforcement scenarios. Users can edit and amend these policies as their needs evolve. Legacy artifact management tools that claim similar policy-as-code capabilities added it by way of acquisition. This kind of bolt-on solution often forces users to manage admin configurations in multiple places. Cloudsmith policy management is native to the platform with all controls and options under the “Policies” tab. These policies also apply across Cloudsmith’s multi-format repos, so you can write a policy once and apply it globally.

Cooldown policies: Closing the remediation window

It’s impossible to predict what packages attackers will target next. So, when a new supply chain attack occurs against a package you depend on, what do you do in the window between when the attack begins and a CVE surfaces? That’s the most dangerous time because you may pull a compromised package without realizing it. Without a cooldown policy, that package enters your environment unchecked.

 address zero-day threats by hiding newly published packages from the index for a configurable period (e.g., 3-7 days). Threat researchers typically identify and report malicious packages within the first few hours or days after publication. The cooldown window provides a default buffer for threat researchers to catch up. If no advisory emerges during the cooldown window, the package releases into your environment once it ends. For security-focused teams managing active CVE incidents, this is one of the more operationally specific controls in the feature set; it targets the exposure window directly, rather than just blocking on severity at a static point in time.

Continuous risk detection: Enforcement that reflects current threat data

Vulnerabilities can go undetected for years after a package is published, or a dependency that was clean on Monday may have a critical CVE attached to it by Thursday. Regardless of how long a package has been in your private repository, you need a way to check it against current threat data.

. Rather than rescanning packages on a schedule, Cloudsmith extracts metadata from each package at sync time and continuously matches it against OSV.dev. When a new CVE, EPSS update, or malicious package record lands in the feed, and Cloudsmith finds a match with a package in your registry, this triggers your policies to re-evaluate the package and take the associated action, e.g., quarantine.

OSV.dev draws on a wide range of data sources, including NVD, GitHub Security Advisories, ecosystem-specific databases like PyPI and RubyGems, and malicious package records covering npm, NuGet, PyPI, and RubyGems, among others. EPSS scores are embedded directly, making them available as policy inputs without any additional integration work.

The result is policies that evaluate against a live view of current threat data, not whatever the feed showed when the package first arrived.

Every policy evaluation Cloudsmith runs produces a decision log entry: what triggered, what data informed the decision, what action the policy took, and why.

In a compliance review, e.g., SOC 2 Type II, DORA, FedRAMP, PCI-DSS, or CRA, log data is the evidence that your controls are real and operating as specified. In an incident response scenario, it’s the audit trail that tells you what was in your environment and what your policies did about it.

Decision logs are queryable via API, which means they integrate into whatever reporting or observability tooling your team already uses.

Why these capabilities reinforce each other

These capabilities cascade into and connect with each other. Continuous risk detection updates the risk profile that policy management evaluates against. Policy evaluations, including cooldown windows, produce decision log entries. Decision logs close the audit gap that makes enforcement defensible in a compliance review.

Cloudsmith delivers a continuous control plane for safely consuming open source dependencies. That's the structural difference between a security program built on Cloudsmith’s security features and one that relies on point-in-time scanning and downstream pipeline gates.

 about what security enforcement looks like for your environment.

How Cloudsmith security features work: policy, risk detection, and the audit trail

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

On August 4, 2026, a self-propagating worm began 

publishing malicious versions of the npm packages keyv and cacheable

, is still developing as we publish, and the list of affected 

 packages has grown through the day to 2,236 package versions. Below we cover what we know so far, how to check whether your organization is exposed, and the controls that stop this class of attack from reaching your builds.

Beginning around 10:53 UTC on August 4, an attacker started pushing malicious releases to legitimate, well-established 

 packages. We know these were not a set of newly published typosquatted packages; the attacker is publishing new 

 of real packages that teams already depend on.

The scale of this attack is significant - tracking so far points to roughly 

 published across them. Several packages received a dozen or more malicious versions in a matter of hours, and new versions were still appearing past 13:20 UTC.

The affected packages sit deep in the JavaScript dependency graph. 

 are transitive dependencies of a large range of common tooling, so most teams that install them never explicitly chose them directly. Weekly download volume for some of these packages rivals the most popular libraries on 

, which gave the campaign a very large potential blast radius.

The activity carries the hallmarks of the 

. The malicious payload is delivered through install-time lifecycle (preinstall) scripts. Once executed on a developer or CI machine, it harvests credentials and tokens and uses any recovered 

 publish tokens to push malicious versions to other packages the compromised account controls. That self-propagation is why a handful of initial compromises turned into hundreds of packages within hours.

It’s also important to note that if you’re running 

, released roughly a month ago, it no longer runs lifecycle scripts by default. Organizations that have upgraded and not re-enabled script execution are substantially protected even if a malicious version was pulled, because the payload never runs on install. However, teams still on older 

 clients, or that have explicitly enabled install scripts, do not have that inherent protection.

Exposure comes down to two questions: did you install an affected version, and could it run on install?

 Compare the packages and versions in your lockfiles (

 against the current indicators. Community trackers are maintaining live lists; the tagged dataset at 

 are both being updated as the campaign expands. Because the affected set is still growing, treat any single snapshot as a lower bound and re-check.

Match on whole package names, not substrings.

 When scripting your own checks, anchor on exact package names. Loose substring matching produces false positives (for example, flagging an unrelated package that merely contains an affected name as a fragment) and wastes triage time.

 The malicious versions were published in a bounded window on August 4. A version of an affected package that predates that window is not part of this campaign. Confirm the specific version, not just the package name.

Check whether install scripts can execute.

 client version and whether lifecycle scripts are enabled in your environments. If you are on 

 with scripts disabled by default, an affected version that was pulled but never executed represents materially lower risk.

 If a malicious version could have run in a developer or CI environment, rotate 

 tokens, cloud credentials, and any secrets that were reachable from that environment, and review recent publish activity on your own packages.

Search your Cloudsmith registry for any cached versions & quarantine. 

If your organization doesn’t have a cooldown or malware policy in place, there's a chance a malicious version was already requested by a developer or pipeline and cached in Cloudsmith - search for any affected versions and quarantine them.

If you find only pinned references in old, dormant projects, the immediate risk is usually low, since a locked dependency tree will not pull a new malicious version on its own. The real exposure is a fresh install or a lockfile refresh that resolves to a compromised version.

This attack is just another example of why pulling directly from a public registry into your builds is a risk worth removing. Cloudsmith sits between the public registry and your developers and pipelines as a single, policy-enforced control point, which changes the outcome in three ways.

While there are many client-side cooldown solutions built into native package managers, this can often be difficult to manage at scale for enterprises. Regardless of client version or script settings, Cloudsmith moves enforcement to the server-side by removing newly published upstream versions for a defined window before they become installable. Attacks like this one depend on speed: a malicious version is published and pulled into builds within minutes or hours, then withdrawn. 

 means those versions are never served to your teams during the window when they are most dangerous, buying time for the ecosystem to flag and remove them.

 Packages flowing through Cloudsmith are scanned for malware and also matched against our comprehensive database of malware advisories. With 

, you can define policies that block versions flagged as malicious or matching known indicators. When a package is identified as compromised, the policy stops it from being distributed to any consumer behind Cloudsmith, without waiting for every developer to update a manual blocklist.

 Because installs resolve through Cloudsmith rather than directly from the public registry, you get one place to enforce controls, one audit trail of exactly what entered your environment, and the ability to answer "were we exposed?" from your own records instead of reconstructing it across every machine and pipeline. Cooldown and malware policies only protect what actually routes through them, so 

 is ensuring your package installs go through the proxy rather than reaching upstream directly.

By applying these safeguards in Cloudsmith, you can greatly reduce the likelihood of being affected by the frequent supply chain attacks we are seeing across the open source ecosystem.

Keyv and Cacheable npm packages compromised in active supply-chain attack

The software supply chain landscape changed forever in early-to-mid 2026. What began as a series of isolated credential-theft incidents quickly mutated into a highly coordinated, multi-registry, self-propagating 

 campaign.

By abusing trusted relationships, hijacking CI workflows, poisoning build caches, and even embedding execution scripts inside compiled native binaries, the threat actors behind this campaign (tracked as 

) bypassed traditional static scanner defences.

As of the time of writing, this is a somewhat complete, chronological teardown of the three distinct waves of this campaign: 

Shai-Hulud, Mini Shai-Hulud and similar worms

The Shai-Hulud worm lineage first surfaced in late 2025 as a direct credential stealer targeting the npm ecosystem. However, on May 11th, 2026, a highly automated, modernised variant called Mini Shai-Hulud struck with vastly expanded scope. While it heavily impacted npm, compromising more than 170 packages across the TanStack, Mistral AI, UiPath, and OpenSearch ecosystems, the worm simultaneously breached the broader software supply chain, orchestrating coordinated attacks against PyPI, RubyGems, Docker Hub, and even malicious extensions within VS Code.

Unlike the earliest waves of Shai-Hulud that relied specifically on stolen static developer credentials, Mini Shai-Hulud (believed to have been created by a different group to TeamPCP), gained entry to these diverse environments via entirely new approaches, like pull request workflow misconfigurations in GitHub Actions (as seen in the 

 compromise).

The basic workflow looked like this. An attacker submitted a pull request from a fork. This triggers a workflow that grants write access to the base repository's cache. The attacker proceeds to poison the cache with malicious payloads. Hours later, a legitimate maintainer merges a commit, triggering the standard release workflow. And this all concludes with the release run pulling the poisoned cache and executing the malicious payload invisibly.

Rather than exposing static tokens, the worm scraped live tokens directly from the GitHub Actions runner’s active memory (the 

). Depending on the target ecosystem, it then exchanged these temporary workflow credentials for registry-specific publish tokens, using OIDC token exchange endpoints for 

, or harvesting raw API keys for RubyGems and container registries like 

.

This allowed the published packages, container images, and extensions to carry valid SLSA Build track provenance signatures. To defenders, the updates appeared completely legitimate and officially attested across all affected registries. It’s the equivalent of deepfakes for the software supply chain.

Perhaps the most malicious aspect of this multi-registry wave was its defence mechanism. Once inside a developer's local machine or build server (whether pulled via a Python 

 package, or a VS Code extension) the payload established a background daemon named 

. This daemon monitored whether its stolen tokens had been rotated or revoked, acting as a dead man’s switch. If a defender revoked the token, the daemon immediately triggered a local script that executed 

, wiping the victim's entire home directory to eliminate forensic traces and punish the developer.

 represents the third evolution of the Shai-Hulud family of worm attacks, compromising hundreds of 

 components (including packages within the 

 namespaces).

In this workflow, a simple 

 command that drops the Miasma payload. Again, the tactics and techniques of this Shai-Hulud worm have changed multiple times so far this year. Most security scanners and manual reviewers focus closely on scripts blocks in 

 triggers).

Miasma bypassed this completely by abusing 

, for context, is a legitimate config file used to compile native C++ Node.js add-ons. When a package containing this file is installed, the npm client automatically spawns 

. The attackers embedded direct command execution wrappers inside the 

 target configs. The system executes the malicious payload during compilation, completely avoiding the need for suspicious 

 lifecycle scripts.

Miasma focused heavily on capturing cloud identities instead of static keys, implementing collectors specifically designed to steal active GCP and Azure SSO credentials. Furthermore, if the infected CI container had access to the host's Docker socket (

), the malware would’ve performed a Docker escape. It identifies and terminates security monitoring containers (such as Step Security’s 

), creating a privileged Alpine container to write passwordless 

, and altered local DNS resolution to block telemetry reporting domains.

Discovered on June 8th, 2026, straight after the Miasma variant, the campaign expanded to the Python ecosystem, targeting critical academic genomics and phenotype analysis packages on 

).

In this attack, a simple Python Import loads a 

 extension which executes embedded javascript. The embedded javascript code executes a final Bun payload which exfiltrates to a GitHub endpoint.

In a major evasion upgrade, the attackers did not modify any Python source files. Instead, they embedded the malicious JavaScript loader inside the compiled Rust/C++ binary extension (

).

When a researcher imports the package via Python (

 file. The shared object discreetly initialises and runs an embedded JavaScript engine to execute the payload. This makes the new attack completely invisible to code-reviewers looking at Python source files.

The payload's primary file, 

, contains a massive block of comment text representing a fake LLM jailbreak prompt. The decoy simulated classified briefings, asking for technical steps on weaponising biological agents and designing nuclear devices. This was a deliberate attempt to pollute static analysers and AI-assisted tooling, causing them to choke, flag false positives on safety boundaries, or even worse, misclassify the file as a prompt-injection experiment rather than a credential-stealing worm.

Instead of a standard server, the Hades variant registered dozens of GitHub repositories using the compromise-controlled user account 

. The repositories used underworld-themed naming conventions (like 

. The exfiltrated data was stored in an encrypted envelope format, signed with GPG keys.

In August 2026, the open-sourced Mini Shai-Hulud codebase was weaponised in one of the most widespread multi-registry campaigns to date. The outbreak began with the compromise of 

's account. This was the primary developer behind popular, heavily downloaded packages like 

.

From this single entry point, the worm exponentially expanded into over 444 packages across 2,000+ published releases, hit 100 packages in the 

 ecosystem alone, and aggressively turned every infected machine into an automated propagation node.

The execution chain relies on the 

 dropper. To evade standard JavaScript static analysis tuned for Node.js patterns, the 

 file detected the host architecture, downloaded a bundled 

 runtime, and proceeded to execute a massive, heavily obfuscated payload named 

.

Rather than stopping at passive credential dumping, this variant actively probed and harvested deeper infrastructure credentials: It actively queried AWS IMDSv2 and ECS endpoints, enumerated AWS SecretsManager paths, read mounted Kubernetes ServiceAccount tokens, and extracted HashiCorp Vault secrets across KV v1 & v2 mounts. It even hunted local crypto wallets like bitcoin wallet files. It was observed that exfiltration calls were routed to a dynamic domain endpoint. Crucially, if the server returned an execute payload in its JSON response, the worm immediately executed it using 

, giving the threat actors live remote code execution on infected dev machines and CI runners. Finally, if the primary C2 server failed, the worm fell back to using stolen GitHub tokens to automatically create public GitHub repos containing base64-encoded stolen data, tagging the repo descriptions with a distinctive campaign marker. This time 

.

To ensure propagation, the worm scraped 

 creds or even exchanged GitHub Actions OIDC tokens to auto-publish patch updates of packages the maintainer controlled. It inserted 

 as an optional dependency, allowing the payload to silently cascade into downstream installs without causing build failures. Furthermore, it even expanded on the infection vectors directly inside dev workflows by writing malicious GitHub Actions workflows disguised with the name 

, as well as altering AI-related dev tooling via poisoned 

Shai-Hulud-style worms will continue to change shape

 or leaking of a complex piece of malware like the Shai-Hulud worm typically triggers a significant shift in the threat landscape. When a sophisticated framework (originally tightly controlled by an advanced group like TeamPCP) becomes publicly accessible, it lowers the barrier to entry for a much wider, more disorganised pool of actors. Independent operators, smaller cybercriminal syndicates, and even security researchers looking to understand its mechanics can dissect the original codebase. This democratisation of advanced tech means that features previously requiring high-level engineering, such as automated supply-chain propagation or complex credential harvesting, become plug-and-play modules for anyone with basic development skills.

Without a centralised command structure like TeamPCP directing its deployment, the evolution of Shai-Hulud has naturally fragmented into highly specialised or experimental variants (such as 

). Newer threat actors are combining Shai-Hulud’s core self-propagating mechanisms with different payloads or evasion techniques tailored to their specific objectives. For instance, some variants strip away the heavier components to create lightweight stealth tools, while others swap out the exfiltration methods to target different developer ecosystems beyond 

. This fragmentation complicates defense strategies, as defenders can no longer rely on a single set of behavioural signatures or specific infrastructure indicators associated with the original group.

Furthermore, this post-TeamPCP era accelerated the timeline of dual-use engineering, where threat actors repurpose and optimise techniques from Shai-Hulud in unexpected ways (as seen in the 

). Independent devs often modify the codebase to patch flaws left by the original authors (such as fixing loud fallback routines or refining how the worm handles OIDC token exchanges). Because these new variants are built and deployed by completely unrelated clusters of users, the attribution of attacks becomes incredibly muddy. The signature architecture of Shai-Hulud is no longer a reliable indicator of 

 is attacking, but rather a reflection of a shared, open-source repository of commodity supply-chain threats. This is glaringly the case with alleged 

If the evolution of Shai-Hulud proves anything, it's that attackers are exceptionally creative and relying purely on reactive remediation is a losing strategy. When malware can pass SLSA attestations, bypass 

 inspection via native builds, and hide inside compiled binaries, you simply cannot predict every vector. It only takes one compromised token to trigger a massive downstream disaster. While rapid incident response remains essential, putting heavy effort into proactive preventions, such as universal package cooldown policies and strict pipeline boundaries is the only way to neutralise these threats before they execute. Stopping the attack at the gate will always be easier than cleaning up the damage after a worm gets through.

If you found this breakdown useful and want to keep up with the evolving threat landscape of malicious dependencies and open-source malware, join our upcoming webinar: 

Inside the Open Source Malware Attack Landscape

) to discuss real-world attack vectors and how to protect your software pipelines.

The evolution of Shai-Hulud-style worms

 is scheduled for release on August 26th 2026, and it’s full of really exciting updates for security, DRA, networking and more! We exclude enhancements with the status of “

. What are we looking forward to in Kubernetes 1.37?

The 1.37 release includes 

’ in this Kubernetes release. From these, just 

 enhancement for DRA now graduating to GA.

A long list of 

 enhancements are in the tracker, including the ability to connect to a localhost NodePort service on NFTables (IPv4 & IPv6) using a userspace proxy (

 flag being added to StatefulSet rolling update strategies (

).

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

Here are a few of the changes that Cloudsmith team are most excited about in the 1.37 release:

#6072 Standard numaNode device attribute for DRA

Kubernetes 1.37 introduces the standardisation of 

) as a globally recognised DRA device attribute. I’m excited to see this Alpha enhancement in 1.37. It unifies how hardware-specific memory topologies, like the memory controller, are exposed alongside existing attributes like 

. By establishing a single, consistent naming convention and introducing specialised helper functions into the 

 library, Kubernetes users should now be able to achieve seamless, cross-driver co-placement and advanced attribute matching (

 hardware configs where PCIe topologies alone were insufficient. Moving this complexity out of custom code and into a native standard means platform teams can finally guarantee high-performance, low-latency hardware alignment with absolute, cross-cloud portability.

Nigel Douglas - Head of Developer Relations




#5758 Per-container ulimits configuration

I am incredibly excited to see this enhancement land in Kubernetes 1.37 because it finally tackles a long-standing headache for anyone running heavy, production-grade workloads. This new KEP introduces a 

 within the Pod API. This grants users fine-grained, per-container control over 

 resource limits (such as open files and process counts) on Linux nodes. This native support eliminates the need for brittle, non-portable workarounds like modifying host configs or custom entrypoint scripts, allowing high-concurrency workloads and databases to optimise performance securely and in a scalable way in multi-tenant clusters. This change will propagate these limits directly to container runtimes via the CRI, utilising a runtime handler to dynamically detect node support. For years, platform engineers have had to jump through hoops just to prevent too many file open errors. Finally bringing this natively into the Pod API is a massive win for cluster security.

Jason Myers - Technical Content Marketer



#1710 Speed up recursive SELinux label change

) graduating to stable is great from a security standpoint. It fundamentally changes how volumes are attached to containers on systems with SELinux in enforcing mode. Traditionally, the container runtime had to recursively relabel every individual file and directory on a volume before a Pod could even start - a process that was notoriously slow for massive datasets, error-prone on near-full disks, and impossible on read-only filesystems. By switching the default behaviour to leverage the Linux kernel's native “

“ mount option, Kubernetes can now instantly assign the correct SELinux label to an entire volume at the mount point without a time-consuming file-system walk. While this drastically accelerates Pod startup times, its truest impact is defensive. By eliminating the need for the container runtime to dynamically change file permissions on the fly, this enhancement effectively blocks host-path exploitation techniques (like 

) where an attacker attempts to trick the cluster into relabelling and exposing critical host files.

Add Recreate Update Strategy to StatefulSet

 for StatefulSets addresses a long-standing 

 that has plagued users for years. Previously, if a StatefulSet update was triggered with a broken config (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 config 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 users to manually delete the Pod to unblock the controller.

The new 

 strategy provides a more aggressive alternative to the standard 

. It allows the StatefulSet controller to prioritise reaching the desired state by terminating existing Pods before creating new ones, effectively bypassing the waiting for ready deadlock. This change transforms what was previously documented as a known issue into a manageable configuration, ensuring that automated pipelines can recover from misconfigurations without manual human intervention.



WAS: Integrate Workload APIs with Job controller

 sig-apps

The enhancement is a major step forward for native support to 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 (

 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.



 sig-apps

This enhancement introduces a 

 parameter (either an absolute number or a percentage) to the 

 strategy for Kubernetes StatefulSets. Currently, StatefulSet updates are limited to processing one pod at a time, which can severely slow down rollouts for large clusters or applications with long startup tasks. By allowing multiple pods to be updated simultaneously, this feature brings StatefulSets closer to feature parity with Deployments, enabling significantly faster rollout times for stateful clustered applications that can tolerate having multiple replicas or followers offline at once.

 sig-api-machinery

This enhancement seeks to optimise the 

 performance and simplify its codebase by eliminating the resource-heavy, traditional internal API types (

) that act as conversion and validation hubs. Because many APIs have matured to a stable v1 version, maintaining these distinct internal types is no longer necessary and incurs significant CPU, memory, and maintenance overhead during request processing and large list operations. The project will execute in two phases. First, it makes internal types memory-identical to preferred versioned types to achieve up to a 

 during conversions. Secondly, it replaces internal types entirely with Go type aliases before eventually removing them altogether.



 sig-api-machinery

This enhancement proposes enabling the 

 feature gate by default to resolve severe API server scaling and timeout issues during CRD version migrations. Currently, when a controller establishes a watch on a cold cache, the 

 fetches the stored CRD versions from etcd and converts them sequentially to the requested version before returning them. At high scale (like, with clusters over 10,000 workloads running Kueue), this sequential conversion process can take several minutes, triggering etcd timeouts and causing the API server to fail with 500 errors. Enabling this feature by default allows the API server to decode and convert these watch events concurrently, drastically reducing processing time and preventing cluster failures during large-scale version upgrades.



 sig-api-machinery

Added in v1.35 as beta (disabled by default), the in-tree Storage Version Migrator (

) controller within the Kube-Controller-Manager (

) is finally graduating to stable in v.1.37. This KEP simplifies and automates data rewrites for at-rest storage. Resource rewrites are essential when a preferred storage schema changes (like 

) or when encryption-at-rest keys are updated. Unfortunately, performing this manually via kubectl is error-prone and scales poorly. By migrating the original out-of-tree SVM migrator controller into the core codebase under a new 

 API group, this proposal allows users to easily trigger efficient data migrations utilising the garbage collection cache. Once a migration successfully completes, the controller also handles updating the CRD status to safely remove references to old, unused storage versions.



 sig-api-machinery

This proposal introduces support for the 

 data format in Kubernetes API servers and clients as a high-performance alternative to JSON. While native Kubernetes resources use 

 to minimise CPU time and heap churn, CRDs cannot easily use Protobuf due to its reliance on compile-time code generation. Adopting CBOR as a self-describing binary format solves this gap. The benchmarks show it can make custom resource encoding up to 

. The rollout includes standard content negotiation (

), support for streaming via CBOR sequences, and client-side feature gates with automatic JSON fallbacks to ensure seamless backward compatibility with older API servers.

 sig-cli

I mentioned back in the 1.34 release how the introduction of KYAML will 

. Finally graduating to Stable status in the 1.37 release, KYAML is a Kubernetes-compliant YAML output format that uses a specific subset of standard YAML (called flow style) that eliminates common syntax pitfalls. By always using curly brackets 

 quotes for strings, it removes whitespace sensitivity and type-coercion bugs while still allowing comments and trailing commas. This will definitely improve the overall reliability of Kubernetes going forward.

Allows setting any FQDN as the pod's hostname



, allowing users to set any arbitrary FQDN up to 64 bytes as a pod's hostname. Aimed at easing the migration of legacy applications (like Kerberos) that relied on specific hostnames for authentication or permissions, this feature bypasses default cluster-suffix restrictions and writes the custom FQDN directly to the pod's 

 file (excluding Windows containers). To mitigate kernel limits, validation will reject strings over 64 bytes or those violating RFC 1123 standards, and the field is strictly mutually exclusive with 

 sig-network

Graduating to Stable in 1.37, 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 NameIsDNSLabel standard, finally allowing users to create Services with names like 

localhost NodePort userspace proxy for NFtables



Cloudsmith Blog

Everything Cloudsmith shipped in Q3 2026

How continuous risk detection replaces point-in-time scans with real-time monitoring

Trust your software supply chain from ingestion to production

Tensorlake SDK npm package compromised

OIDC removed long-lived credentials from your pipelines. What about your laptop?

Cloudsmith expands support to Nix

Cloud Native Digest - July 2026

How to use Cloudsmith as a dependency firewall

Cloud Native Digest - June 2026

How Cloudsmith security features work: policy, risk detection, and the audit trail

Simplify repository structure with connected repositories

Keyv and Cacheable npm packages compromised in active supply-chain attack

The evolution of Shai-Hulud-style worms

Kubernetes 1.37 – What you need to know

How to configure time for cooldown policies