By submitting this form, you agree to our 

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

Artifact Security Maturity Assessment

 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



 sig-network

This net new enhancement introduces an opt-in userspace TCP proxy to the 

 kube-proxy backend. This proxy bridges a critical feature gap by allowing workloads to access NodePort services via localhost (IPv4 and IPv6) under nftables. This is a capability that currently exists for 

 equivalent. Activated explicitly via the 

 flag, this Layer 4 forwarder supports key features like 

 external traffic policies, while intentionally excluding non-TCP protocols (UDP/SCTP) and leaving the iptables and IPVS backends completely unchanged.



Make NFtables the default kube-proxy backend



 KEP mentioned above, Kubernetes 1.37 is laying the groundwork to eventually make 

 the default backend for kube-proxy. This will ultimately replace the older 

 systems entirely. Because this shift requires newer Linux kernels (version 5.13 or higher) and continuous stability testing, the 1.37 release focuses on preparing users rather than making an immediate switch. Starting in this version, Kubernetes will actively issue log warnings to clusters that rely on the default 

 setting, advising administrators to either explicitly lock in 

 before the official default switch occurs in 

. This all culminates with the removal of IPVS mode in kube-proxy (

 sig-auth

Graduating to beta, this enhancement aims to solve a long-standing issue where a resource that cannot be decrypted or decoded completely blocks Kubernetes API operations like 

 storage to fix it. The proposal introduces more informative retrieval error messages to pinpoint the broken data, along with a new 

 that allows admins to bypass storage checks and safely delete malformed resources directly through the K8s API. While this simplifies recovery in scenarios like lost encryption keys or stuck namespace deletions, it’s worth noting that forcefully deleting a broken resource will bypass finalisers and garbage collection, potentially leaving behind orphaned underlying processes.



 sig-auth

Graduating to stable, this enhancement introduced a secure and automated mechanism to deliver X.509 certificates directly to pods without using bearer tokens, which helps preserve the integrity of mTLS auth. It establishes two key components: a 

 API specifically for pod certificate issuance, and a 

 projected volume source that lets the kubelet provision keys and certs automatically. By shifting the responsibility of enforcing node security boundaries to the K8s API-Server, this mechanism makes it significantly easier and safer for both in-tree and third-party tools (like HashiCorp Vault) to issue client and server certificates via standard 

), a new cluster-scoped Kubernetes API designed to safely distribute X.509 trust anchors (root or intermediate certificates) to workloads. Previously, clusters relied on clumsy workarounds like copying a 

 into every namespace or hardcoding static CA certs.

To complement this, a new kubelet projected volume source allows workloads to easily consume these trust anchors directly from the container's filesystem, automatically updating them on the fly during certificate rotations without requiring application restarts.


 sig-node

This enhancement extends the Pod API to now support Pod-level resource requests and limits (specifically for CPU, memory, and hugepages) alongside existing container-centric settings. By allowing tightly coupled containers within a pod to share a unified resource pool, this feature simplifies resource management and eliminates the need for meticulous, per-container configs. Ultimately, this change enables dynamic intra-pod resource sharing, which reduces waste, improves overall resource utilisation, and better accommodates workloads with unpredictable or bursty demands.



Enable Writable cgroups for unprivileged containers

 sig-node

Introduced as an Alpha stage feature in 1.37, we’re seeing a new 

. This enhancement allows unprivileged containers to securely manage and write to their own sub-cgroups, providing fine-grained resource control directly through the Kubernetes API instead of relying on broad, less-secure runtime-level configurations.



 sig-node

Graduating to stable in 1.37, the proposed Node Declared Features framework allows Kubernetes nodes to dynamically advertise their active, feature-gated capabilities directly to the control plane. By exposing these features, components like the scheduler and admission controllers can automatically manage version-skew issues. This includes activities like ensuring pods are only scheduled on compatible nodes and blocking unsupported API operations, all without requiring users to manually configure complex taints, tolerations, or node labels.



 sig-node

Kubernetes 1.37 introduces a native 

 and the CRI. This allows users to configure fine-grained POSIX resource limits (like open files and process counts) per container, ultimately eliminating the need for host-level workarounds that could otherwise cause issues. To maintain system stability and cluster security, the proposal restricts the feature to the privileged (

) level, enforces strict validation, and even integrates with newly-graduated node-declared features to ensure pods requiring custom limits are only scheduled on compatible nodes.

 sig-node

By allowing drivers to specify at the 

 level that node-local setup is unnecessary, the kubelet can bypass standard gRPC preparation and unpreparation calls. This bypass speeds up the container lifecycle, allowing container startup & termination to proceed immediately for supported devices.



Resource Claim Status with possible standardised network interface data



 sig-node

Graduating to stable in 1.37, this KEP introduces a new 

 API. This allows DRA drivers to report arbitrary, driver-specific status data, such as operational conditions and standard networking details (IPs, MAC addresses, and interface names) directly to the resource claim. The enhancement improves observability, simplifies troubleshooting, and enables third-party controllers to integrate allocated resources into higher-level network services.



 sig-node

This framework-assisted method exposes DRA device metadata like PCIe addresses and mediated device UUIDs directly to workloads via standard JSON files mounted using the Container Device Interface (

). By allowing DRA drivers to populate a metadata field (either immediately during resource preparation or deferred via NRI hooks during sandbox creation), the framework automatically handles file generation, directory structuring, and container bind-mounting. This design provides proper container-level isolation per resource request, ensures backward compatibility, and eliminates the need for complex, error-prone custom controllers currently required by workloads like 

Scheduler Preemption for In-Place Pod Resize



 sig-scheduling

Updating the Kubernetes Scheduler to automatically actively create space for Deferred In-Place Pod Resizes by preempting (or evicting) lower-priority pods on fully-utilised nodes certainly aligns the behaviour with the preemption logic used for newly created pods. Currently, in-place resizes that exceed a node's capacity do not trigger preemption, resulting in deferred status and requiring manual intervention or risking disruptive external controller behaviours (like OOM-kills or node rescheduling). While the proposal aims to automate resource scaling and reduce workload disruptions, it intentionally keeps broader scheduling tasks (like binding) out of scope and highlights key risks, such as performance overhead from deferred pod queues, double-preemption during scheduler restarts, and the potential for over-preemption. This will all be addressed using aligned resource-fit calculation logic by Beta.



 sig-scheduling

Graduating to Stable in 1.37, this enhancement introduces device taints and tolerations to DRA. This improvement mirrors the existing node taint model to handle hardware issues gracefully. By applying taints via DRA drivers or user-defined 

, clusters can block new pods from scheduling onto degraded or offline hardware (

) or evict currently running pods for maintenance (

). Users can bypass specific taints by adding matching tolerations directly to their 

. This allows workloads to run on degraded devices or during testing at their own risk. All while informational taints can be published for hardware monitoring without altering scheduling.



 sig-scheduling

To eliminate the rigidity of exact attribute matching across different hardware vendors, this net new improvement introduces 

 to DRA. By evaluating scoped CEL expressions on candidate devices to synthesise virtual grouping keys, users can easily pair GPUs and NICs without waiting for vendors to standardise attribute names. Here’s a quick sample of bridging disparate schema within the 

Speed up recursive SELinux label change



 sig-storage

Graduating to Stable in the 1.37 release, speeding-up SELinux volume mounting by replacing the slow, recursive file-by-file relabelling process with the Linux 

 mount option is a huge improvement. This change applies the required SELinux context to an entire volume at once. Having been rolled out across Kubernetes 1.36 and 1.37 through feature gates like 

, the new default applies context mounting automatically while providing opt-out mechanisms (

) for edge cases that rely on traditional recursive relabelling.



 sig-storage

This Beta improvement proposes extending the Kubernetes 

 plugin to score nodes during dynamic persistent volume provisioning based on available storage capacity. Users can configure this global policy to either prioritise nodes with the most free space (the default, to allow for future volume expansion) or nodes with the least sufficient space (to pack workloads and reduce node count/costs).



Add user fields to atomic write volumes



 sig-storage

Graduating to Alpha in 1.37, we’re seeing optional 

) to allow setting custom owner UIDs on mounted files. This solves a long-standing issue for apps with strict file-ownership requirements (like MongoDB or SSHD) that currently default to root ownership. It’s also worth noting it enables non-root pods running under restricted security policies to set correct file permissions without needing privileged 

Configurable tolerance for Horizontal Pod Autoscalers



 sig-autoscaling

The Horizontal Pod Autoscaler (

) currently uses a fixed, cluster-wide default tolerance of 10% to prevent rapid scaling churn - called "

". Unfortunately, this is a global setting and is often too coarse. Especially for large or sensitive workloads where minor percentage shifts represent hundreds of pods or delay critical scale-ups. This KEP adds an optional, per-HPA tolerance field (within 

) that allows users to override the global default on a per-workload basis. By letting devs fine-tune scaling thresholds independently for scale-up and scale-down actions, HPAs can become significantly more responsive without altering the core scaling algorithm or introducing major operational risk.



Support scaling to/from zero pods for object/external metrics



 sig-autoscaling

In the Kubernetes 1.37 release, there were improvements to the existing Beta release, natively allowing the HPA to scale workloads down to zero replicas (

) and back up based on object or external metrics (such as message queue length). The key change to Beta introduces an explicit 

 status condition on the HPA object. This enables the controller to differentiate between an automated scale-to-zero event and a manually paused deployment. The changes here also expanded end-to-end and integration test suites to ensure safe cluster behaviour.

Native Histogram Support for Kubernetes Metrics



 sig-instrumentation

Graduating from Alpha status to Beta in 1.37, this KEP introduces a 

 feature gate to expose Prometheus Native Histograms across Kubernetes control plane components alongside existing classic metrics. By transitioning from fixed bucket boundaries to dynamic exponential buckets, Native Histograms deliver a ~10x reduction in time series storage overhead and significantly sharper latency resolution for detecting performance issues. The dual-exposition model ensures full backward compatibility, allowing team-level migration without breaking existing dashboards or alerts.

 sig-network

Kubernetes 1.37 outlines the deprecation and eventual removal of the under-maintained 

, steering users instead toward the newer 

 backend as older kernels phase out of LTS by the end of 2026. Rather than archiving the code in a separate repository, the project plans a clean, multi-release removal via the 

 feature gate. The transition spans five stages: starting with deprecation warnings and documentation updates back in v1.35 (Stage 1), introducing the current feature gate in v1.37 (Stage 2), before disabling IPVS by default in v1.40 (Stage 3), and fully removing the IPVS codebase in v1.43 (Stage 4). The release team cleaned up the feature gate itself in v1.46 (Stage 5).

Add Resource Health Status to the Pod Status for Device Plugin and DRA



, with past milestones including the start of the cycle back in May and the 

 on June 16th. Upcoming technical milestones involve the 

 on July 22nd - the week before Kubecon Japan. The official v1.37 release comes out on Wednesday the 26th August.

Kubernetes 1.37 – What you need to know

Kubernetes 1.36 – What you need to know

Kubernetes 1.35 – What you need to know

Kubernetes 1.34 – What you need to know

Kubernetes 1.33 – What you need to know

Nigel Douglas

Head of Developer Relations

If time’s just a construct of human perception, does that mean all package managers interpret time differently? And what does that have to do with cooldown policies?

 help protect your software supply chain from zero-hour threats by holding packages for a set period of time to allow threat intelligence to catch up. But where does a package get held, and how does that impact how you configure your cooldown policy?

You can implement cooldown controls on either the client-side and on the server-side. This post highlights the difference between where the cooldown policy lives, and how that impacts your ability to implement and scale that policy. We’ll explore how they can be defined differently in various ecosystem package managers, and why all this flexibility actually might hinder (not help) the security posture of our software supply chain.

JavaScript developers most commonly pull 

 registry. The most popular Javascript package manager, 

, included the concept of a minimum release age (

 represents the number of days a dev must wait before they can receive a newly-released software dependency, as a single number unit. However, not all JavaScript package managers work the same way. The 

 client, for example, chose a completely different unit of time. We can see that 

 specifically treats cooldown (within the 

 registry also introduced the cooldown field 

) represents the configured cooldown period in 

) supports days and weeks in a more humanly-readable approach, similar to 

This leaves JavaScript teams in a situation where securing a polyglot Node.js environment requires a math degree and a cheat sheet! If your team wants to implement a cooldown policy and uses a mix of 

 (as only a few examples), you need to translate a basic 48-hour quarantine policy into days, minutes, seconds, and human-readable string tags simultaneously. This arbitrary config drift is more than a tedious task, it’s a genuine security liability. When security policies are this fragmented across tools running in the same language ecosystem, misconfigurations are more likely.

The Python ecosystem is similar to JavaScript when it comes to representations of time. Astral’s 

 package manager provided cooldown controls in 

. It uses relative durations, but also supports a bunch of other duration formats (inside 

The result in the Python ecosystem is a case of duplicate standards. While more modern, lightning-fast tools like 

 embrace highly flexible relative text strings, standard 

 leans heavily into the rigid syntax of ISO 8601. For security teams trying to enforce a consistent supply chain guardrail across a variety of developer endpoints and pipelines, this introduces a layer of translation friction. We aren't simply configuring the time window, we’re also managing entirely different syntactical philosophies from what was discussed in the JavaScript ecosystem - just to keep a volatile package at bay.

Package Managers with no support for Cooldown Policies

And that brings us to the lack of support for cooldown policies in many other popular language ecosystems. As of the time of writing, languages like 

 provide client-side support for cooldown controls in any direct configuration field.

In the absence of built-in cooldowns, devs without server-side or private artifact repository solutions rely on strict version pinning as their primary line of defence. But version pinning is a double-edged sword:

Pinning to an older version should (generally speaking) keep you safe from a zero-day compromise in today's release, but it leaves you exposed to older, known CVEs.

Pinning only works if you trust the version you are pinning. If you update your config to pin a newly released version and that version happens to be a compromised release from a hijacked maintainer account, well then, your client will happily download and index that malware regardless.

Without a cooldown policy acting as a quarantine buffer, devs updating their pinned dependencies are essentially playing Russian roulette with the latest release.

On a positive note, the open source supply chain is evolving all the time. Where cooldown controls don't exist today, they could very well exist tomorrow. What’s important to software developers and security teams is that we can curate or enforce security controls that seamlessly apply across the wide variety of languages and runtime ecosystems.

That’s where an artifact management platform like Cloudsmith comes to the rescue. The platform provides cooldown policy support for 

, with additional format support planned:

Cloudsmith supports cooldown policies in npm and Python

If time really is just a construct of human perception, package managers have certainly taken that philosophy to heart. But the real headache is trying to actually implement security controls in the real world. 

This is fundamentally a client-side crisis

We are forcing devs and their pipelines to rely on local, fragmented CLI tooling to enforce security policies that should be uniform. The fragmentation here is a massive vulnerability:

Different naming conventions and arbitrary time units across clients make universal configurations very challenging.

Some client-side tools allow granular exclusions, while others offer no cooldown protection at all.

While centralised registries like Cloudsmith work overtime to curate, scan, and secure upstreams, they need to account for rogue, outdated, or poorly designed local clients that bypass standard safeguards.

Trying to secure a polyglot codebase where the security posture of your entire pipeline is dictated by the weakest client-side tool in your stack is a logistical nightmare.

Cloudsmith solves this systemic headache by providing a single control plane for your entire software supply chain. By defining a universal policy that sits above individual ecosystems, you don’t waste time tweaking configurations across a wide range of runtimes. With Cloudsmith, you define the policy once, and enforce it across your entire workspace.


If you’re interested in learning more about Cloudsmith 

How to configure time for cooldown policies

If you were hoping for a relaxing summer break without a software supply chain attack, the latest news will disappoint. Early on July 14th 

 identified that an attacker compromised AsyncAPI repositories and used the projects’ own CI/CD pipelines to publish four malicious npm packages. Together these packages see more than 2.9 million downloads a week, with @asyncapi/specs accounting for roughly 2.7 million of them.

Here’s what we know so far, why so many conventional defenses would have let these packages through, and what a governed control layer does about it.

The attacker exploited a misconfigured GitHub Actions workflow in the asyncapi/generator repository to steal a highly privileged token belonging to the project's automation account. They used that token to push a commit that triggered the release pipeline, which published trojanized packages to npm under the trusted @asyncapi namespace. A second repository in the same organization was then used to publish the highest-impact package, @asyncapi/specs.

For a full breakdown of the attack, Wiz’s post provides an excellent 

This attack has two details that matter for what follows. First, the malicious code was hidden inside otherwise legitimate source code and it ran on package import rather than install. Second, once triggered it installed a persistent credential stealer that swept for browser passwords, SSH keys, npm and GitHub tokens, and cloud credentials.

Why security scanners may have allowed these packages through

None of the usual signals a build environment relies on would have stopped these downloads.

 The packages came from the correct namespace, published through the project’s real release pipeline using a real maintainer token.

The versions were brand new, so no intelligence existed yet: 

At the moment of publication, no advisory named these versions as malicious. A team pulling @asyncapi/specs@latest in the minutes or hours after publication would have received a clean bill of health from every feed, because the community hadn't identified the compromise yet. This is the zero-hour window, and pulling directly from a public registry means running straight into it.

Install-time scanning looked in the wrong place:

 Many defenses focus on preinstall and postinstall hooks, because that's where supply chain payloads have historically lived. This payload executed on import instead. Tooling watching only the install lifecycle would have seen nothing.

 Even a developer inspecting the source would have had to scroll past hundreds of blank spaces to find the payload.

Cloudsmith Blog

Kubernetes 1.37 – What you need to know

How to configure time for cooldown policies

Inside the AsyncAPI npm supply chain attack

How to use Cloudsmith as a dependency firewall

Cloud Native Digest - June 2026

What Cloudsmith shipped in Q2 2026

A dependency firewall gives your scanner better inputs

Start secure, stay secure with WizOS and Cloudsmith

Dependency attacks start before your scanner runs

Cloudsmith credentials are now detectable by GitHub Secret Scanning

Authenticate to Cloudsmith with your Google Cloud identity

Inside the Mastra npm supply chain attack