By submitting this form, you agree to our 

Explores AI-driven development, rising supply chain attacks, and new regulatory requirements.

2026 Artifact Management Report

 have identified a new software supply chain attack on the 

”. A series of malicious packages are masquerading as a new AI coding agent called 

, the malicious package was reported minutes after being identified as containing a malicious payload on the 

 community did a great job in removing these suspicious packages from the registry so quickly, the 

 advisories weren’t able to classify these packages in time. But that’s okay, since they have successfully been removed and pose no threat right now.

OSM scanned the binaries, and the payload appears to be infostealers focused on cloud and AI credential harvesting across 

 storage. These payloads are adjusted for Windows and MacOS environments. A list of 

As always, if you’re a Cloudsmith user, you can apply age-based (

) policies to block newly published packages. In the case of the stardrop campaign, the malicious npm packages were all removed less than a day after the campaign began.

 is one of the most effective ways to stop this class of attack, giving security researchers (like our friends at OSM) time to identify the suspicious payload. In 2025, 

99% of malicious npm packages were identified and officially verified within 72 hours

, so implementing a simple cooldown policy significantly reduces this kind of attack vector.

Nigel Douglas

Head of Developer Relations

Stardrop: New cross-industry npm campaign

, an extremely popular HTTP client for JavaScript, suffered a malicious payload injection attack. While the malicious code was removed within a matter of hours, the package’s popularity means that millions of build systems may have been infected.

This attack is the latest in a growing list of software supply chain attacks, this time linked to 

, where the actors took advantage of the popularity of open source packages to serve malicious payloads to millions of victims. npm credentials have repeatedly emerged as a weak point that malicious actors attack.

The attack vector appears to have been a compromise of the

npm account of one of axios’s maintainers, giving a malicious actor the ability to publish new versions of axios to the 

 registry and add malicious dependencies to the payload.

The malicious payload was added to two branches of axios between 00:20 and 01:00 UTC on 31 March. The malicious version remained live on npm for around 2 hours, in part because the maintainer’s

npm account was the only admin account, preventing other collaborators from shutting down the attack until the case was picked up by npm’s administrators.

The attack appears designed to facilitate crypto-related fraud. The attacker modified 

, which is a new malicious software package that did not exist before yesterday.

 was published 18 hours before the axios updates. The compromised payload, in a new version of 

, deploys a remote access trojan that’s tailored for the host’s operating system. This is a textbook supply chain malware injection incident. Systems that configure their build managers to install the latest version by default are subject to compromise in this style of attack. That’s probably a huge number of systems, given that 

 is a popular project, with over 100 million weekly downloads on 

How to secure your supply chain against future attacks

The axios breach comes less than a week after another popular package, 

, the canonical Python public registry. Very popular open source packages are an attractive attack vector for malicious actors. Once a malicious payload like this enters your software supply chain, it can do irreversible damage almost immediately. Cleanup is often a slow and frustrating process, and regulations such as the EU's Digital Operational Resilience Act (DORA) and the Cyber Resilience Act (CRA) require companies to report these incidents within 24 hours, or face substantial fines.

Here’s how to protect your software supply chain:

Route all package requests through a private registry proxy, like Cloudsmith.

 Sitting between your developers and public registries, Cloudsmith creates a checkpoint, applying security policies before packages reach build environments or developers’ local machines.

This proxy buffer is a key component of Cloudsmith. With Cloudsmith as your control plane, every public package, and base Docker container image, is subject to scanning and security policies before anything reaches your build systems.

 was created less than a day before the attack. It was published specifically as part of a malicious payload before the compromised axios versions were published. Blocking package versions less than 7 days old (the specific age is configurable) is one of the most effective ways to stop this class of attack, giving security researchers time to identify the vulnerability.

In 2025, 99% of malicious npm packages were identified and officially verified within 72 hours – implementing a simple cooldown policy significantly reduces the attack vector.

Cloudsmith users with a cooldown policy in place would block 

 even before malicious behaviour was reported, protecting their software supply chain from this attack.

You can configure cooldown policies in many package managers, but Cloudsmith allows you to set the policy at an organisational level, so it’s enforced across formats, teams, and build systems consistently.

Subscribe to real-time threat intelligence feeds.

 Cloudsmith subscribes to databases like OSV.dev and the OpenSSF Malicious Packages project, which update in near real-time.

. Using a system like Cloudsmith to integrate these feeds into your package policies means you get automatic protection as new threats are identified.

 can act on these intelligence feeds, so anti-malware policies trigger even after the cooldown period ends. We’ve written before about how 

Cloudsmith’s policy manager protects your software supply chain

Creating a Malicious Package policy in Cloudsmith

. This one serves as a malware detection gate. EPM runs 

 the Cloudsmith security scan completes during package synchronisation, making scan results available as 

. In this case, the policy code loops over the 

 array, which is the OSV malware data from the scan. For each vulnerability object, it checks, “does the ID start with the string 

So what does this policy do in practice? It flags any package that has been reported as known malicious as part of the OpenSSF Malicious Packages project. "

" is used specifically in vulnerability feeds to indicate malware-related findings. Once a match is found, Cloudsmith will execute the 

 for this policy, such as to quarantine, tag, or block package promotion.


If you are interested in evaluating proactive security policies for poisoned/malicious software packages, 

 about protecting your software supply chain from attacks like the one on axios.

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

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

” we are seeing 80 enhancements in all listed within the 

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

’ in this Kubernetes release. From these, just 

 are currently graduating to stable, such as 

 enhancements graduating to that GA status.

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

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

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

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


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

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

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

Nigel Douglas - Head of Developer Relations


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

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

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

#5793 Manifest-based Admission Control configuration


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

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

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

Mutable Container Resources when Job is suspended


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

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

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

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

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

Add Recreate Update Strategy to StatefulSet


Starting in Kubernetes 1.36, the introduction of the 

 for StatefulSets addresses a long-standing 

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

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

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

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

WAS: Integrate Workload APIs with Job controller


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

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

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

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

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

, which is whether the release team should maintain separate 

 policies or to unify them into a single parameter where a 

 equal to the total replicas represents strict gang scheduling.

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

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

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

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

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

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

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

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

 objects. By using CEL's object instantiation alongside 

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

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

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

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

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

This proposal introduces a mechanism to mitigate 

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

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

 of objects after a write and updating the 

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

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

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

Separate kubectl user preferences from cluster configs


 feature introduces a dedicated configuration file (typically located at 

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

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

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

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

 to prevent the execution of untrusted binaries.

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

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

 standard, finally allowing users to create Services with names like 

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

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

Extend PodResources to include resources from DRA


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

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

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

, guaranteeing that resource assignments are preserved across Kubelet restarts.

The primary benefit of this enhancement is 

granular observability for next-gen hardware

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

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

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

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

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

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

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

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

API for external signing of Service Account tokens


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

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

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

To maintain consistency and security, the 

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

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

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

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

In the first phase, the authoriser performs 

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

In the second phase, these conditions are enforced during the 

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

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

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

 lookups. Concretely, the enhancement extends the 

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

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

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

The authority to impersonate a specific identity (

Right to perform specific actions on behalf of that identity (

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

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

By introducing these prefixed verbs like 

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

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

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

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

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

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

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

 for better diagnostics and requires explicit confirmation through 

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

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

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

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

Kubernetes 1.36 – What you need to know

Thousands of platform engineers and security experts are heading to KubeCon + CloudNativeCon Europe 2026, making it the definitive cloud-native event in Europe. Stop by Cloudsmith at Booth 570 to say hello and check out our activities throughout the week. There’s 

With hundreds of talks on the schedule, it can be hard to know where to start. Here is our curated roadmap to ensure you get the most out of your time on the ground.

📍 RAI Amsterdam (Europaplein 24, 1078 GZ Amsterdam, Netherlands)
👋 Booth 570
🗓️ March 24 - 26, 2026

 (Thales SIX GTS France) will dive into the messy reality of the Software Bill of Materials (SBOM). They plan to pull back the curtain on why current open-source and cloud-based tools (despite all their promises) frequently generate conflicting package lists and inconsistent vulnerability reports when tasked with scanning complex container images.

This talk is particularly electrifying for the security community because it tackles the compliance anxiety triggered by the EU’s Cyber Resilience Act (CRA). As the CRA shifts SBOMs from a nice-to-have transparency initiative to a legal necessity for software lifecycles, the industry is waking up to a major problem, which is inconsistent data. By dissecting the technical roots of these discrepancies, Bufalino and Blaise aren't just pointing out flaws, they will also be providing a roadmap for developers to ensure their tooling is actually CRA-compliant. For anyone navigating the shift toward a transparent and trustworthy software supply chain, this session offers the technical clarity needed to turn these metaphorical bombs into secure builds.

2. Modelpack: Standardising the packaging and distribution of AI/ML Models

, a Distinguished Architect at Red Hat, tackles one of the most pressing bottlenecks in modern infrastructure: the chaotic fragmentation of AI/ML integration within the cloud-native ecosystem. Block, a seasoned expert in helping organisations scale open-source solutions, will break down how the current wild west of competing formats and runtimes is actively stifling innovation. He will introduce 

, a CNCF Sandbox project designed to act as the universal translator for AI/ML artifacts, allowing them to finally speak the same language as established tools like Kubernetes, ORAS, and Harbor.

The security and DevOps communities are closely watching this session because it addresses the Day 2 operations nightmare of managing AI at scale. As AI moves from experimental notebooks to production-grade Kubernetes clusters, the lack of standardisation creates massive technical debt and security blind spots. Block’s exploration of ModelPack and emerging artifact standards offers a glimpse into a future where AI models are managed with the same consistency and rigour as container images. For anyone struggling to bridge the gap between data science and cloud-native engineering, this talk provides the blueprint for a unified, scalable, and manageable AI supply chain.

3. Kubernetes security at Shopify scale: Automating security across an infrastructure monrepo

In this session, Senior Infrastructure Security Engineers 

 will pull back the curtain on how one of the world’s largest e-commerce platforms secures its massive infrastructure monorepo. Drawing from their deep backgrounds in cloud defense and 5G network security, Wu and Garg will detail the high-stakes challenge of managing thousands of services where a single misconfiguration could impact millions of merchants. They will demonstrate how Shopify moved beyond manual checkbox security by building an automated pipeline that combines Semgrep for static analysis and Open Policy Agent (OPA) for real-time policy enforcement.

This talk is a must-attend for the security community because it provides a battle-tested blueprint for solving the velocity vs. security dilemma we’re all too familiar with. While many orgs struggle with friction between DevOps and Security teams, Shopify’s approach shows how to bake guardrails directly into the developer workflow without slowing down deployment. Attendees will gain rare insights into the so-called rough patches of scaling open-source security tools and leave with a practical framework for automating risk detection across complex, high-traffic Kubernetes environments.


4. To upstream or not? Why becoming the maintainer of your dependencies matters

, a Principal Software Engineer at Elastic and an OpenTelemetry code owner, dives into the strategic heart of modern software engineering. Markou moves beyond the typical 

Cloudsmith Blog

Stardrop: New cross-industry npm campaign

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

Kubernetes 1.36 – What you need to know

13 KubeCon Europe 2026 sessions not to miss

LLMs on Kubernetes: same cluster, different threat model

Securing LLM dependencies against serialisation attacks

Top 10 most popular LLM models on Hugging Face

Extend EPM policies to Hugging Face artifacts

Kubernetes 1.35 – What you need to know

Securing the intersection of AI models and software supply chains

Breaking the "Department of No": Ship fast but also secure

AI generated code is changing the demands being put on artifact management