Cloud-native security incidents hit 97% of organizations as attacks shift to the supply chain

Nearly every organization running cloud-native infrastructure suffered a security incident over the past year, according to Red Hat's State of Cloud-Native Security 2026 report: 97 percent of surveyed organizations reported at least one cloud-native security incident. At the same time, a wave of supply chain compromises shows attackers increasingly targeting the systems that build and ship software — CI/CD pipelines, package registries and build caches — rather than the Kubernetes cluster itself.

Incidents have become the default

The report, examined in a dev.to analysis of Kubernetes security trends, paints a grim operational picture. Most incidents stem not from sophisticated intrusions but from everyday mistakes, and the business impact is measurable: 74 percent of organizations delayed or slowed application deployments in the past twelve months because of security concerns, 52 percent reported increased remediation effort, and 43 percent reported reduced developer productivity.

Confidence, however, is not tracking reality. While 56 percent of respondents describe their day-to-day security posture as highly proactive, only 39 percent actually have a mature, clearly defined security strategy, and roughly 22 percent operate with no defined strategy at all. Meanwhile, 64 percent of organizations point to the EU Cyber Resilience Act as the main driver of their 2026 security investments — meaning compliance pressure is rising even where the underlying strategy is missing.

The supply chain becomes the front line

That the software supply chain is now a primary attack surface was demonstrated in May 2026, when attackers hit the TanStack project on npm. According to InfoQ's post-incident reporting, the attackers compromised 42 npm packages and published 84 malicious package versions within six minutes.

The attack chain combined several techniques: a disguised fork of the TanStack router carrying a malicious pull request, cache poisoning of GitHub Actions workflows, and exploitation of the insecure pull_request_target workflow pattern. The result was the ability to generate OIDC tokens that could publish directly to npm — no stolen npm credentials required. The injected malware went after developer and CI environments specifically, harvesting credentials for AWS, GCP, Kubernetes, Vault and GitHub, plus SSH keys and npm configurations. For Kubernetes operators the lesson is direct: a compromised build pipeline is a straight path to cluster credentials.

The fallout spread quickly. The Hacker News reported that OpenAI confirmed two employee devices were affected and that code signing certificates had to be rotated, and that the attacker group known as TeamPCP extended the campaign to other ecosystems, including packages related to Mistral AI and UiPath.

The platform itself is not off the hook

While pipelines absorb the attention, Kubernetes add-ons remain a genuine weakness. In October 2026 Dell shipped security updates for its Container Storage Modules fixing several flaws — CVE-2026-63688, CVE-2026-67269 and CVE-2026-67273 — that allowed unauthenticated administrative access, compromise of every node in a cluster through a single custom resource, and cluster-wide read access to Kubernetes Secrets along with the ability to create cluster-wide RBAC resources. All versions before 1.17.0 were affected, a reminder that a little-watched storage add-on can undermine an entire cluster's security.

What the report suggests teams do

The report and the incidents point to a shared set of practices. Supply chain security — SLSA provenance verification, Sigstore signing and consistent dependency auditing — is treated as baseline rather than optional; Red Hat's data shows 61 percent of organizations with a clearly defined strategy report notably higher confidence in their supply chain security. CI/CD hardening matters too: avoiding the pull_request_target pattern, isolating caches, and pinning GitHub Actions to fixed SHAs — steps TanStack itself took after the attack. On the cluster side, the guidance is to treat extensions as part of the attack surface, with regular updates, CVE monitoring and an inventory of custom resource definitions, and to enforce least privilege with short-lived OIDC-based credentials and a proper secret manager rather than long-lived tokens and environment variables.

Why it matters

The 97 percent figure confirms that cloud-native security incidents are no longer exceptional events but a background condition of running Kubernetes at scale, and the TanStack attack shows that the most efficient path into a cluster now runs through the developer toolchain upstream of it. The gap Red Hat identifies — between how proactive teams believe they are and how many have an actual strategy — is where the risk concentrates, and it comes just as regulations like the EU Cyber Resilience Act push more spending. The mitigations are known and mature; what many organizations lack is the strategic commitment to build them into the platform rather than bolt them on after an incident.