In March 2025, Wiz Research disclosed a chain of vulnerabilities it named IngressNightmare — four CVEs in the ingress-nginx controller, a component running in an estimated four out of every ten internet-facing Kubernetes clusters. Chained together, the bugs let an unauthenticated attacker reach the Kubernetes API server and extract every secret in the cluster. None of it involved application code. The flaws existed because the default Helm chart, the Terraform module, and the YAML manifests that thousands of teams copy into their own repositories shipped with an admission webhook exposed to untrusted network traffic by design. That is the uncomfortable core of infrastructure as code security: the fastest way to stand up a cluster is also the fastest way to replicate a misconfiguration across every environment that reuses the same code. Prisma Cloud built a large part of its business on catching exactly this class of problem. Here is what it catches, what it structurally misses, and how teams are closing the gap.
What Is Infrastructure as Code Security, and Why Does Kubernetes Make It Harder?
Infrastructure as code security is the practice of scanning Terraform, Helm, Kustomize, CloudFormation, and raw Kubernetes YAML for exploitable misconfigurations before that code ever provisions a real resource — catching the problem in a pull request instead of in production. Kubernetes makes this materially harder than a single cloud resource does, because one manifest or Helm release can simultaneously define networking policy, service-account identity, storage mounts, and workload scheduling, and a mistake in any one dimension can compromise the others. Red Hat's 2023 State of Kubernetes Security report found that 67% of organizations had experienced at least one security incident in their Kubernetes environments in the preceding twelve months, and misconfiguration was the single largest reported cause, cited by 37% of respondents — ahead of runtime attacks and even ahead of unpatched vulnerabilities. The code that defines the cluster is, in practice, the largest attack surface the cluster has.
How Do Misconfigured Helm Charts and Terraform Modules Actually Lead to Breaches?
They lead to breaches by turning a one-time coding mistake into a fleet-wide default, and the pattern shows up repeatedly in public incidents. In 2018, security firm RedLock — the company Palo Alto Networks acquired later that year and rebuilt into what is now Prisma Cloud — disclosed that Tesla was running a Kubernetes dashboard with no authentication enabled, exposing cloud credentials that attackers used to mine cryptocurrency inside Tesla's AWS account. The dashboard's default access settings were never an application bug; they were an infrastructure default nobody's IaC review had flagged. Three years later, independent researchers scanning the public internet found roughly 2,600 exposed etcd servers — the key-value store that holds every Kubernetes secret, including credentials and TLS keys — reachable without authentication, most of them the result of Terraform or kubeadm bootstrap scripts that never closed the default port. The 2025 ingress-nginx CVEs (CVE-2025-1097, -1098, -1974, and -24514) followed the same shape: a webhook default, baked into IaC, replicated everywhere.
Where Does Prisma Cloud Fall Short on Kubernetes and IaC Security?
Prisma Cloud falls short where most broad CNAPP platforms fall short: it was assembled from acquisitions — RedLock for cloud security posture management in 2018, Bridgecrew (and its open-source scanner, Checkov) for IaC scanning in 2021, Twistlock for container runtime, and PureSec for serverless — and stitching those modules together left seams that show up as operational friction. Practitioners on G2 and Gartner Peer Insights consistently cite two recurring complaints: alert volume that outpaces triage capacity across dozens of policy packs, and a steep licensing model where meaningful IaC and CI/CD coverage sits behind higher-tier add-ons. The deeper structural gap is traceability. Prisma Cloud can tell you that a Terraform module opens port 2379 to 0.0.0.0/0; it is far weaker at telling you which commit introduced that line, which pull request approved it, and whether the image that eventually runs on top of that infrastructure was built from source that matches its SBOM. IaC scanning and software supply chain provenance are treated as separate products with separate consoles, which means a finding at scan time and a compromise at runtime rarely get correlated back to the same root cause.
What Kubernetes IaC Misconfigurations Do Teams Still Miss in 2026?
Teams still miss a short, repeatable list of misconfigurations, and it hasn't changed much in five years because the defaults themselves haven't changed. Privileged containers and hostPath volume mounts remain common in Helm charts pulled from public repositories, effectively handing a compromised pod root access to the underlying node. Missing or overly permissive NetworkPolicies leave clusters on Kubernetes' default allow-all pod-to-pod networking, so a single compromised container can reach every other workload in the namespace. RBAC bindings that grant cluster-admin to service accounts — often added "temporarily" during initial setup and never revoked — show up in a large share of the clusters scanned by every major CNAPP vendor's own published research. Secrets stored as plaintext values in ConfigMaps or environment variables, instead of pulled from a secrets manager at runtime, persist because it's the fastest way to make a demo work. And unpinned image tags such as :latest in deployment manifests remain a live supply chain risk: without a digest pin, the exact same manifest can pull a different, potentially tampered image on every redeploy, which defeats image scanning done at any single point in time.
How Should Teams Shift IaC Security Left Without Slowing Down Deploys?
Teams shift IaC security left successfully by moving the check to the pull request instead of the release, using policy-as-code so the rule set is version-controlled alongside the infrastructure it governs. Concretely, that means running Open Policy Agent, Conftest, or Kyverno policies against Terraform plans and Kubernetes manifests as a required CI check — not a nightly scan — so a developer sees "this Helm values file grants cluster-admin" in the same PR comment thread as a linting failure, minutes after pushing, rather than in a weekly security report. Maintaining a small number of pre-approved, pre-hardened module and chart templates (a "golden path") for the 80% of infrastructure that's boilerplate — VPCs, ingress controllers, RBAC roles — cuts the surface area teams have to review from scratch. Finally, scan-time coverage has to be paired with continuous drift detection: IaC defines intent, but manual kubectl edits, emergency hotfixes, and third-party controllers change what's actually running, and a tool that only checks the Terraform file has no visibility into a cluster that has drifted away from it. Red Hat's same 2023 survey found that 90% of respondents had delayed or slowed deployment specifically to address security concerns after the fact — the exact cost that shifting left is meant to eliminate.
How Safeguard Helps
Safeguard treats infrastructure as code as part of the software supply chain, not a separate compliance checklist, which changes what a finding looks like in practice. When Safeguard flags a Terraform or Helm misconfiguration, it resolves the finding to the specific commit, pull request, and author that introduced it — not just the file and line — so remediation goes to the person who can fix it fastest instead of into a shared backlog. Because Safeguard already tracks SBOMs and build provenance for the artifacts your infrastructure deploys, an IaC finding like an unpinned image tag is correlated with the actual image digest history behind it, closing the exact gap that let the :latest-tag problem persist across tool categories in first-generation CNAPPs. Policy-as-code checks run as a gate in CI before merge, covering Terraform, Helm, Kustomize, and Kubernetes RBAC in one pass, with a single alert stream instead of a module-per-console structure — so a small platform team isn't triaging the same drift-vs-misconfiguration signal in three different dashboards. Safeguard also runs continuous drift detection between declared IaC state and live cluster and cloud configuration, so a manually applied RBAC change or an emergency hotfix that widens a NetworkPolicy gets flagged the moment it diverges, not at the next quarterly audit. For teams under SOC 2 or similar frameworks, that same commit-level attribution and continuous evidence trail doubles as audit-ready documentation, turning IaC security from a point-in-time scan into a running record of who changed what, when, and whether it was safe.