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.
Editorial analysis by NHI Mgmt Group, based on content published by Orca Security: “Taking the Helm: Navigating Kubernetes Security Risks from Runtime to Source Code”.
By the numbers:
- 70% of organizations now use Kubernetes in their cloud environments.
- 50% of organizations using Kubernetes run at least one unsupported cluster version.
- 93% have overprivileged service accounts.
Key questions
Q: What breaks when Kubernetes resources cannot be traced back to their Helm source?
A: Teams lose the ability to assign ownership, determine blast radius, and see whether a runtime issue is isolated or repeated across many deployments.
Q: Why do excessive service account privileges create such a serious risk in Kubernetes clusters?
A: Excessive service account privileges increase risk because they turn a single pod compromise into a cluster-wide control problem.
Q: What are the signs that a Kubernetes programme is losing governance control?
A: Unsupported versions, repeated template-driven misconfigurations, and service accounts that carry broad permissions all indicate that the programme is drifting away from governable state.
Practitioner guidance
- Trace runtime findings back to chart origins Require every high-risk Kubernetes finding to be linked to its Helm chart, template, repository, and code owner before remediation is assigned.
- Review service account scope against workload need Compare each service account’s effective permissions with the workload’s actual API calls and remove permissions that exist only for deployment convenience.
- Inventory reusable templates across environments Identify charts and templates that generate multiple clusters, pods, secrets, or config maps so one misconfiguration cannot remain hidden in repeated deployments.
Bottom line: Kubernetes risk in this article is driven by governability problems as much as by technical exposure, especially where service accounts and unsupported clusters are involved.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 1 day ago by NHI Mgmt Group
12/06/2026 9:30 am
Cloud-to-dev traceability is now a Kubernetes governance control, not just an operational convenience. When runtime resources cannot be traced back to the chart, template, file, and owner that created them, remediation becomes a guessing exercise. That breaks the accountability model that Kubernetes governance depends on, especially in environments where the same Helm artifact can fan out across many deployments. Practitioners should treat source linkage as part of control ownership, not a reporting enhancement.
A few things that frame the scale:
- Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems. Organisations failing to scope AI access properly are 4.5x more likely to experience a security incident, according to the 2026 Infrastructure Identity Survey.
A question worth separating out:
Q: Should teams prioritise Helm template review or runtime detection first?
A: Teams need both, but source review becomes the higher-leverage control when the same chart or template is reused broadly. Runtime detection finds the exposure, while template review stops it from reappearing in the next deployment. The right sequencing is to contain what is live and fix the reusable source that created it.
👉 Read our full editorial: Cloud-to-dev tracing exposes Kubernetes risk at the source
This post was modified 1 day ago by NHI Mgmt Group