Kubernetes and Container Security Statistics Guide: Misconfiguration and Image Risk

Kubernetes is now the default way most organisations run production workloads, but the security numbers quoted about it are usually stripped of their source, sample and year. This page collects the figures that can be traced to a primary publisher: the Cloud Native Computing Foundation (CNCF) annual survey, Red Hat's State of Kubernetes Security Report 2024, Sysdig's 2025 Cloud-Native Security and Usage Report, Datadog's State of DevSecOps 2026, the Shadowserver Foundation's internet scan of Kubernetes API servers, and the CISA Known Exploited Vulnerabilities (KEV) catalog. Each figure carries its publisher, edition and basis (survey or telemetry), because a respondent survey of 600 people and telemetry from millions of containers answer very different questions. It is written for platform engineers, cloud security leads and CISOs who need defensible numbers for risk registers, board papers and tooling cases. Most sources here are vendor reports, so treat them as indicators, not census data. Last reviewed: November 2026.

Key takeaways

• Kubernetes is mainstream in production. 80% of organisations in the CNCF 2024 Cloud Native Survey ran Kubernetes in production, up from 66% in 2023, and 93% were using, piloting or evaluating it.
• Incidents are near universal in surveys. 89% of respondents to Red Hat's State of Kubernetes Security Report 2024 had at least one container or Kubernetes security incident in the previous 12 months; 45% had a runtime incident and 40% detected a misconfiguration.
• Security slows delivery. 67% of the same respondents delayed or slowed deployment because of container or Kubernetes security concerns, and 46% reported lost revenue or customers after an incident.
• Machine identities dominate the attack surface. Sysdig's 2025 report found up to 40,000 times more machine identities than human ones, 98% of granted permissions unused, and risky service accounts (admin access without key rotation) in 60% of enterprises.
• Exposure is measurable from the internet. Shadowserver's May 2022 scan found 381,645 Kubernetes API servers answering an unauthenticated version request, nearly 84% of the 454,729 instances it saw.

How to read Kubernetes and container statistics

• Survey versus telemetry: Red Hat asks people what happened; Sysdig and Datadog measure what their agents saw. Survey figures tell you what practitioners experience and fear, telemetry tells you configuration and runtime reality in a vendor's customer base. Never add them together.
• "Incident" is defined broadly: in the Red Hat survey, a detected misconfiguration or a major vulnerability needing remediation counts as an incident. That is why 89% is so high. Quote the breakdown, not just the headline.
• Single-vendor numbers: every figure on this page except the Shadowserver scan, the CNCF survey and the KEV catalog comes from a security vendor's own report. We found no government statistical series on container security.

Adoption: how much is running on Kubernetes

• Multi-platform is normal: the Red Hat platform shares add up to well over 100%, so most Kubernetes users run more than one distribution or managed service. Security baselines have to be written per platform. See the Azure Kubernetes Service Security Hardening Guide for one example.
• Security is no longer the top adoption barrier: the CNCF announcement says cultural and operational change now outranks security as the main challenge, without giving a percentage. That reflects maturity, not lower risk.

Incidents and business impact

All figures in this section are from Red Hat's State of Kubernetes Security Report 2024 (600 respondents, incidents in the 12 months before December 2023 to January 2024).

• Deployment friction: 67% delayed or slowed application deployment because of security concerns, and 33% said their current container security solution itself slows development.
• Top worries: asked to choose one, 33% worried most about vulnerabilities, 27% about misconfigurations and exposures, 24% about attacks and 16% about failing compliance. The report's key findings list gives 30% for vulnerabilities, so quote the chapter figure with care.
• Ownership is spread: 34% named the security team as most responsible for Kubernetes security, while 50% named an IT operations, DevOps or DevSecOps role. Unclear ownership is a theme across the report.
• DevSecOps maturity: 42% described DevSecOps as advanced (security integrated and automated across the lifecycle), 48% as early stage (up from 39% a year earlier) and 10% had no initiative.

Vulnerabilities, images and the supply chain

• Prioritise by runtime context: the gap between images carrying critical or high findings (under 17%) and vulnerabilities in packages actually loaded (under 6%) is the strongest argument in the data for runtime-aware prioritisation. Datadog's 18% figure points the same way from the application side.
• Freshness cuts both ways: pulling a public image within a day of creation (32% of organisations) gets fixes fast but leaves no time for the community to spot a poisoned image. Pin by digest and verify signatures. See the Container Image Security Guide and the Checkmarx KICS Docker image supply chain attack, where trusted images were replaced with credential-stealing versions.
• Known exploitation is rare but real: a keyword search of CISA KEV catalog version 2026.10.21 for Kubernetes, Docker, containerd, runc, ingress-nginx, Rancher and OpenShift product names returned one entry, CVE-2019-15752 in Docker Desktop Community Edition, added on 3 November 2021. Exploitation in container estates is driven far more by misconfiguration and stolen credentials than by orchestrator CVEs.
• Supply chain controls in use: Red Hat respondents most often relied on vulnerability scanners (44%), CI/CD tools (35%), static analysis (34%) and SBOM tools (32%); only 28% used admission controllers and 23% signing or attestation tools.

Configuration, exposure and runtime

• Ephemeral workloads break forensics: with most containers gone within minutes, evidence must be captured by runtime sensors and audit logs as it happens. See the Container and Kubernetes Forensics Guide.
• Benchmark scores flatter: Sysdig's 93% average benchmark pass rate is among customers already running a posture tool, and the report itself notes non-applicable controls may distort it. Newer CIS benchmark versions score lower.
• Exposure is a starting point: an API server that discloses its version is not necessarily open to anonymous actions, but it is discoverable and fingerprintable. Restrict the control plane to private endpoints or allow-listed networks.

Where identity fits: service accounts and machine credentials

Every pod runs as a Kubernetes service account, and most workloads also hold cloud credentials, registry tokens or API keys. The statistics consistently point to identity as the weakest layer.

Replace static cloud keys in pods with workload identity federation, set automountServiceAccountToken: false where pods do not call the API, and audit ClusterRoleBindings to cluster-admin. See the Cloud Workload Identity Guide, How to audit Kubernetes cluster admin bindings and the RWTH Aachen study of secrets in Docker Hub images, which shows how credentials baked into images leak at scale.

What the numbers mean for defenders

1. Inventory first: list every cluster, its distribution, version and API endpoint exposure. Multi-platform estates (Red Hat) and internet-visible API servers (Shadowserver) make this the first gap to close.
2. Fix identity next: remove unused permissions and admin-bound service accounts, rotate or eliminate long-lived keys, and move to federated workload identity.
3. Prioritise vulnerabilities by runtime use: scan images in CI and registries, but rank remediation by whether the package is loaded and reachable.
4. Gate the supply chain: pin images by digest, verify signatures with an admission policy, and generate SBOMs. Pilot admission policies in audit or warn mode, then enforce per namespace, with a documented exemption and rollback path.
5. Detect at runtime: enable Kubernetes audit logging and a runtime sensor; with containers living minutes, detection that relies on later investigation will miss the evidence.
6. Agree ownership: write down who owns cluster security between platform, DevOps and security teams, since respondents disagree.

Metrics to track in your own estate

• Exposed control planes: number of clusters with a public API endpoint, target zero or allow-listed only.
• Privileged workloads: percentage of pods running privileged or as root, by namespace, trending down.
• Unused permissions: share of granted RBAC and cloud permissions not used in 90 days, measured against Sysdig's 98% benchmark.
• Static credentials in clusters: count of long-lived cloud keys mounted as Secrets, target zero.
• Runtime-reachable criticals: number of critical vulnerabilities in loaded packages and their median age.
• Admission coverage: percentage of namespaces enforcing signature and pod security policies.

Common failure patterns when using these statistics

• Quoting 89% as "breaches": the Red Hat figure includes detected misconfigurations and failed audits. Say "security incident as defined by the survey".
• Treating vendor telemetry as the whole market: Sysdig and Datadog measure their own customers, who already pay for security tooling.
• Recycling the 380,000 figure as current: the Shadowserver scan is from May 2022, and the version mix shows it. Run your own exposure check.
• Mixing bases: the "worried versus experienced" figures in the Red Hat report use only respondents who worried about each issue as the base.
• Ignoring the denominator: platform shares in Red Hat are among 390 Kubernetes users, not all 600 respondents.

Practitioner checklist

• Quote every figure with publisher, edition, basis (survey or telemetry) and sample.
• Inventory clusters, versions and API endpoint exposure across every managed and self-managed platform.
• Remove unused RBAC permissions and bindings to cluster-admin; review service accounts quarterly.
• Replace static cloud keys in pods with federated workload identity.
• Pin images by digest, verify signatures at admission and keep SBOMs for deployed images.
• Prioritise vulnerabilities loaded at runtime and listed in the CISA KEV catalog.
• Enable Kubernetes audit logs and runtime detection, and ship evidence off-cluster.
• Assign named ownership of cluster security between platform and security teams.
• Re-check the CNCF, Red Hat and Sysdig reports each year before refreshing board figures.

Standards and references

• CNCF: CNCF Research Reveals How Cloud Native Technology is Reshaping Global Business and Innovation (2024 survey)
• Red Hat: The State of Kubernetes Security Report 2024
• Sysdig: 2025 Cloud-Native Security and Usage Report
• Datadog: State of DevSecOps
• Shadowserver Foundation: Over 380 000 open Kubernetes API servers
• CISA: Known Exploited Vulnerabilities Catalog
• Kubernetes: Official CVE Feed
• Kubernetes: A Closer Look at NSA/CISA Kubernetes Hardening Guidance

Related NHI Mgmt Group resources: Container Security Guide · Container Runtime Security Guide · Cloud Security Statistics Guide · Non-Human Identity and Secrets Statistics Guide