Articles

Snyk Helm Chart Scanning: Find Kubernetes Misconfigurations (2026)

April 18, 2026 5 min read

The Snyk Helm chart scanning feature doesn’t just find bad configurations; it actually simulates the deployment of your Helm charts to identify potential security and operational risks before they ever hit your cluster.

Let’s see it in action. Imagine you have a Helm chart for a simple Nginx deployment.

# nginx-chart/Chart.yaml
apiVersion: v2
name: nginx
version: 0.1.0
appVersion: 1.16.0

# nginx-chart/templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.16.0
        ports:
        - containerPort: 80

If you run snyk test --file=nginx-chart/Chart.yaml (assuming you’ve configured Snyk for your Kubernetes environment), Snyk will analyze this chart. It doesn’t just look at the YAML itself; it understands the Helm templating and will render the Kubernetes manifests as if Helm were deploying them.

The core problem Snyk Helm chart scanning solves is the "drift" between your declarative Kubernetes configuration and the actual running state. Helm charts are powerful, but their templating and dependency management can obscure potential issues. You might have a values.yaml file that looks benign, but when combined with the chart’s templates and deployed, it could lead to:

  • Security Vulnerabilities: Running containers with excessive privileges, exposing sensitive ports, or using images with known vulnerabilities.
  • Operational Risks: Deploying resources with insufficient requests/limits, leading to resource starvation or instability, or misconfigured network policies that block legitimate traffic.
  • Compliance Violations: Failing to meet security baselines or regulatory requirements due to insecure configurations.

Snyk achieves this by:

  1. Helm Template Rendering: It uses the Helm CLI (or its own internal rendering engine) to process your chart, applying values.yaml and any overrides to generate the final Kubernetes manifest YAML.
  2. Static Analysis: It then applies its extensive ruleset to these rendered manifests, checking for known misconfigurations and security anti-patterns. This includes checks for things like hostPath volumes, privileged containers, missing resource requests/limits, and insecure network configurations.
  3. Vulnerability Scanning: If the chart specifies container images, Snyk will also scan those images for known CVEs.

Let’s say your nginx-chart/values.yaml had a setting that inadvertently enabled a security risk:

# nginx-chart/values.yaml
replicaCount: 3

image:
  repository: nginx
  tag: 1.16.0
  pullPolicy: IfNotPresent

# This is the problematic part
securityContext:
  privileged: true

When Snyk renders the deployment.yaml with this values.yaml, it will produce a manifest that includes securityContext.privileged: true. Snyk’s rules engine will flag this immediately. The diagnostic output might look something like this:

✗ [kubernetes] Container 'nginx' in deployment 'nginx-deployment' is running as privileged.
  Remediation: Avoid running containers as privileged. If absolutely necessary, ensure strict access controls are in place.
  See https://snyk.io/policies/kubernetes/k8s001/ for more information.

The fix is straightforward:

# nginx-chart/values.yaml (corrected)
replicaCount: 3

image:
  repository: nginx
  tag: 1.16.0
  pullPolicy: IfNotPresent

# Removed or corrected securityContext
# securityContext:
#   privileged: false # Or simply remove the entire block if not needed

By setting securityContext.privileged to false (or removing it entirely if it’s not required), you instruct Kubernetes not to grant the container elevated privileges, mitigating the security risk. Snyk works by simulating the outcome of helm template . and then applying its policy engine to the resulting Kubernetes objects, catching issues that are only apparent after Helm’s processing.

Another common scenario is missing resource requests and limits, which can destabilize your cluster.

# nginx-chart/templates/deployment.yaml (partial)
spec:
  template:
    spec:
      containers:
      - name: nginx
        image: nginx:1.16.0
        # Missing resources section
        # resources:
        #   requests:
        #     memory: "64Mi"
        #     cpu: "250m"
        #   limits:
        #     memory: "128Mi"
        #     cpu: "500m"
        ports:
        - containerPort: 80

If Snyk detects a container without resources.requests and resources.limits, it will warn you:

✗ [kubernetes] Container 'nginx' in deployment 'nginx-deployment' is missing resource requests and limits.
  Remediation: Define resource requests and limits for all containers to ensure predictable performance and prevent resource starvation.
  See https://snyk.io/policies/kubernetes/k8s007/ for more information.

The fix involves adding the resources block to your container definition, typically within values.yaml to keep the template clean:

# nginx-chart/values.yaml
replicaCount: 3

image:
  repository: nginx
  tag: 1.16.0
  pullPolicy: IfNotPresent

resources:
  requests:
    cpu: "100m"
    memory: "128Mi"
  limits:
    cpu: "200m"
    memory: "256Mi"

And then referencing these in your deployment.yaml:

# nginx-chart/templates/deployment.yaml (partial)
spec:
  template:
    spec:
      containers:
      - name: nginx
        image: nginx:1.16.0
        resources:
          requests:

            cpu: {{ .Values.resources.requests.cpu }}


            memory: {{ .Values.resources.requests.memory }}

          limits:

            cpu: {{ .Values.resources.limits.cpu }}


            memory: {{ .Values.resources.limits.memory }}

        ports:
        - containerPort: 80

This ensures that Kubernetes has the necessary information to schedule your pod effectively and allocate appropriate resources, preventing one pod from consuming all available CPU or memory and impacting other workloads.

What many users miss is that Snyk doesn’t just check for explicit security settings. It also infers potential issues from the combination of chart values and Kubernetes resource definitions. For instance, a network policy that explicitly denies ingress to a Service might be overlooked by a developer focusing only on the Deployment YAML, but Snyk’s holistic analysis of all deployed Kubernetes objects (as rendered by Helm) can catch this.

The next logical step after ensuring your Helm charts are secure and well-configured is to integrate this scanning into your CI/CD pipeline to prevent misconfigurations from ever reaching production.

Want structured learning?

Take the full Snyk course →