Kubernetes cloud-to-dev tracing: what IAM and security teams need

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

View Full Forum →  |  NHI Foundation Course →