Notifications
Clear all
Topic starter
12/06/2026 12:19 am
TL;DR: 70% of organisations use Kubernetes, while 50% run at least one unsupported cluster version and 93% have overprivileged service accounts, according to Orca Security’s 2025 cloud security report, showing that runtime Kubernetes risk is still driven by lifecycle and access governance gaps. Source context links production findings back to Helm code origins, which matters because remediation speed and ownership now depend on tracing identity and configuration drift to the source.
NHIMG editorial — based on content published by Orca Security: cloud-to-dev tracing for Kubernetes assets and Helm-based remediation context
By the numbers:
- 70% of organizations now use Kubernetes in their cloud environments.
- 50% of organizations using K8s run at least one unsupported cluster version.
- 93% have overprivileged service accounts, which attackers can exploit to escalate privileges, access sensitive data, or disrupt the cluster.
Questions worth separating out
Q: How should security teams govern Kubernetes service accounts with broad permissions?
A: Treat Kubernetes service accounts as machine identities with ownership, purpose, and lifecycle controls.
Q: Why do Helm charts create repeated Kubernetes security risk?
A: Helm charts create repeated risk because one template can be reused across many deployments, which means a single insecure default can propagate everywhere.
Q: What breaks when Kubernetes runtime alerts cannot be traced back to source code?
A: Remediation slows down and accountability becomes ambiguous.
Practitioner guidance
- Audit Helm chart reuse paths Identify every chart and template that produces production workloads, then map where the same definitions are reused across clusters, namespaces, and teams.
- Recertify Kubernetes service account permissions Review service accounts as governed machine identities, not just workload plumbing.
- Require source provenance for high-risk runtime objects Make chart, template, repository, file, and code-owner linkage mandatory for secrets, config maps, and privileged pods so investigators can jump directly from runtime alert to code fix.
What's in the full article
Orca Security's full article covers the operational detail this post intentionally leaves for the source:
- The exact Cloud-to-Dev tracing workflow for Helm-deployed Kubernetes assets.
- How Orca maps runtime objects to Helm charts, templates, code lines, repositories, and code owners.
- The Discovery view workflow for inventorying all resources created from a specific chart or template.
- How the platform positions KSPM and container security together across AWS, Azure, Google Cloud, Oracle Cloud, Alibaba Cloud, and Kubernetes.
👉 Read Orca Security's analysis of cloud-to-dev tracing for Kubernetes risk →
Kubernetes cloud-to-dev tracing: what IAM and security teams need?
Explore further
12/06/2026 9:30 am
Helm-driven Kubernetes sprawl is an identity governance problem disguised as deployment efficiency. The article shows that the same templating model that improves delivery also multiplies risk when permissions and configuration are wrong. In practice, the security failure is not just in the cluster, but in the reusable identity and configuration patterns that create the cluster state in the first place. Practitioners should treat chart reuse as governance scope, not only DevOps convenience.
A few things that frame the scale:
- 93% have overprivileged service accounts, which attackers can exploit to escalate privileges, access sensitive data, or disrupt the cluster, according to The 2024 Non-Human Identity Security Report.
- Only 19.6% of security professionals express strong confidence in their organisation’s ability to securely manage non-human workload identities, according to The 2024 Non-Human Identity Security Report.
A question worth separating out:
Q: What is the difference between Kubernetes security posture management and cloud-to-dev tracing?
A: Kubernetes security posture management identifies risk in the live environment, while cloud-to-dev tracing explains where that risk came from in code and who owns it. The first tells you what is exposed. The second tells you which template or repository created the exposure and where remediation should begin.
👉 Read our full editorial: Cloud-to-dev tracing exposes Kubernetes risk at the source
