Kubernetes misconfigurations are now one of the most common ways container workloads get compromised — not through zero-days, but through pods running as root, missing network policies, or Helm charts that quietly ship a hostPath mount into production. Snyk IaC is one of the more widely adopted tools for catching these problems before they ship, and it works by treating Kubernetes YAML and Helm charts the same way it treats Terraform or CloudFormation: as structured infrastructure code that can be parsed, modeled, and checked against a rule set before a single resource is ever applied to a cluster. Understanding the mechanics — how it renders Helm templates, what benchmarks it checks against, and how it scores severity — matters if you're deciding where in your pipeline to enforce these checks. This post walks through the publicly documented approach Snyk IaC uses for Kubernetes and Helm scanning, without editorializing on whether it's the right tool for your stack.
How does Snyk IaC parse a raw Kubernetes manifest before checking it?
Snyk IaC parses YAML and JSON Kubernetes manifests into an internal structured representation before any rule ever runs against them. When you run snyk iac test against a manifest or a directory of manifests, the CLI first identifies the resource kind (Pod, Deployment, DaemonSet, NetworkPolicy, ClusterRoleBinding, and so on) and normalizes the document into a model that rules can query by field path — for example, spec.containers[].securityContext.privileged or spec.containers[].resources.limits. This normalization step is what lets a single rule, like "containers must not run as privileged," apply consistently whether it's written directly in a Pod spec, inherited from a Deployment template, or generated by a templating tool. Multi-document YAML files (separated by ---) and multiple files in a scanned directory are parsed independently and then evaluated together, so a NetworkPolicy defined in one file can be checked in the context of workloads defined in another.
How does Snyk render Helm charts into something it can actually scan?
Snyk IaC scans Helm charts by rendering them into plain Kubernetes manifests first, then running the same manifest-scanning logic against the output. Helm charts are templates — {{ .Values.replicaCount }} and range loops aren't valid Kubernetes YAML on their own — so Snyk needs a rendering step before it can evaluate anything about securityContext, resource limits, or RBAC bindings. In practice this means pointing snyk iac test at a chart directory (with a Chart.yaml and templates/ folder) and, where needed, supplying a values.yaml or --file override so the template resolves the same way it would during a real helm install or helm template run. Because the rendered output depends entirely on the values passed in, a chart that looks safe with default values can render insecurely with a production values file that disables a securityContext block or adds a hostNetwork: true override — which is why scanning charts with the values actually used per environment, rather than just the chart defaults, is the meaningful test.
What rule set does Snyk IaC actually check Kubernetes resources against?
Snyk IaC ships a built-in library of Kubernetes-specific rules mapped to industry benchmarks, primarily the CIS Kubernetes Benchmark and elements of the NSA/CISA Kubernetes Hardening Guidance. These rules cover the categories most Kubernetes security guidance converges on: workload hardening (root containers, missing runAsNonRoot, allowPrivilegeEscalation: true, dropped vs. added Linux capabilities), network exposure (missing NetworkPolicy resources, services exposed via NodePort or LoadBalancer without restriction), RBAC (wildcard verbs or resources in Role/ClusterRole, overly broad ClusterRoleBindings to system:anonymous or default service accounts), and resource hygiene (missing CPU/memory limits, missing readOnlyRootFilesystem, use of latest image tags). Each finding links back to the specific benchmark control it maps to, so a flagged issue isn't just "this looks wrong" — it's tied to a numbered CIS recommendation a security or compliance team can cite in an audit trail.
How does Snyk decide what severity to assign a finding?
Snyk IaC assigns each finding a static severity — critical, high, medium, or low — based on the security impact of the underlying misconfiguration rule, not on runtime exploitability data pulled from the live cluster. A privileged container or a wildcard cluster-admin binding is rated more severely than a missing resource limit, because the rule authors have pre-classified the blast radius of each misconfiguration class. This is a meaningful distinction from vulnerability scanning: there's no CVSS-style scoring engine recalculating severity per environment, so the same rule produces the same severity everywhere it fires. Teams control what actually breaks a build using the --severity-threshold flag (for example, --severity-threshold=high to fail only on high and critical findings) or by configuring thresholds in the Snyk UI per project, which is how most teams avoid gating every merge on low-severity findings while still blocking the ones that matter.
Can Snyk IaC catch issues that only exist once a Helm chart is actually deployed?
Not from the chart alone — Snyk IaC's Kubernetes/Helm scanning is a pre-deployment, static check, and it depends on Snyk Cloud (which Snyk built out following its 2022 acquisition of Fugue) to add a runtime dimension. The static scan evaluates the manifest or rendered chart as written; it can't know that a ConfigMap referenced by name actually resolves to something dangerous at apply time, or that a cluster's admission controller would reject the config anyway. Snyk Cloud closes part of that gap by continuously scanning live cloud and Kubernetes resources and correlating them back to the IaC source that provisioned them, which is how drift — a resource that was deployed one way but has since been changed directly in the cluster — gets surfaced separately from the IaC scan itself. For teams relying purely on snyk iac test in CI, it's worth being explicit that the check is evaluating the code, not the cluster state.
How does Snyk IaC fit into CI/CD and pull request workflows?
Snyk IaC is designed to run at multiple points in the pipeline rather than as a single gate, using the same snyk iac test command locally, in CI, and via Git integration. Developers can run it from the CLI or an IDE plugin before committing; CI systems like GitHub Actions, GitLab CI, Jenkins, and CircleCI can run the same command as a pipeline step and fail the build based on the severity threshold; and Snyk's native Git integration can post findings as pull request checks when a manifest or chart change is proposed, so reviewers see misconfiguration feedback alongside the diff rather than after merge. Custom policies are also supported: Snyk IaC allows teams to write organization-specific rules using Open Policy Agent's Rego language, which lets a platform team enforce internal standards (like a mandatory label schema or a banned base image registry) using the same rule evaluation pipeline as the built-in CIS-mapped checks.
How Safeguard Helps
Static IaC scanning tells you a Kubernetes manifest or Helm chart violates a known rule — it doesn't tell you which of those violations sit on a path an attacker could actually reach in your specific environment, or whether a chart that passed scanning last quarter has since drifted from what's actually running. Safeguard is built to sit alongside tools like Snyk IaC in a software supply chain security program: correlating manifest and chart findings with what's actually deployed, tracking provenance from source repo through Helm chart through cluster, and giving security teams a single place to see whether a flagged misconfiguration was ever remediated, suppressed, or silently reintroduced in a later chart version. Rather than replacing static IaC checks, Safeguard helps teams answer the harder follow-up questions — ownership, drift, and exploitability in context — that a rule-based scan alone isn't designed to answer.