Helm Chart Security Scanning: Checkov, Kubesec, and CI/CD Gate Integration for Kubernetes Deployments
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
Running helm install on a chart that has never been security-scanned is the Kubernetes equivalent of deploying code that has never been reviewed. The chart may function perfectly and still deploy containers running as root, with no resource limits, with the host network accessible, and with secrets visible in environment variables. None of these issues generate a Helm error. They generate incident reports six months later when an attacker who compromised one pod finds the entire node accessible.
Helm chart security scanning adds static analysis at the rendering stage — after Helm processes the templates but before the manifests reach the cluster. Checkov evaluates rendered manifests against 80+ Kubernetes security policies, Kubesec scores the risk profile numerically, and the CI/CD gate turns a passing score into a deployment prerequisite. The first scan on any long-running Helm chart typically surfaces five to fifteen findings; remediating them takes a few hours and permanently raises the security baseline for every future deployment.
Scanning setup: Checkov and Kubesec in the CI/CD pipeline
Checkov and Kubesec complement each other because they evaluate different aspects of Helm chart security. Checkov applies a broad policy library of 80+ named checks and produces pass/fail results for each, making it easy to identify which specific security controls are absent. Kubesec produces a composite risk score that reflects both implemented security controls and critical risks, providing a single threshold for pipeline pass/fail decisions. Running both in series — Checkov first for detailed findings, Kubesec second for the go/no-go score — gives teams the diagnostic detail needed to fix issues and the binary gate needed to enforce the standard.
Render the chart with production values before scanning to catch environment-specific misconfigurations
Helm chart defaults in Chart.yaml and values.yaml are often set for development convenience, not production security: securityContext fields may be absent, resource limits may be commented out, and service types may default to LoadBalancer rather than ClusterIP. Scan the rendered output using production values with helm template ./my-chart -f values-production.yaml > rendered.yaml && checkov -f rendered.yaml --framework kubernetes, which evaluates exactly what will be deployed rather than the chart defaults. This catches the common failure mode where the chart passes a default-values scan but deploys insecurely with production configuration overrides that disable security contexts.
Configure Checkov to treat root-user and missing resource limits as hard failures in the pipeline
Not all Checkov findings are equal severity — a missing liveness probe is informational, while a container running as root is critical. Configure the CI/CD pipeline to fail hard on specific high-severity check IDs using checkov -d ./chart --framework helm --check CKV_K8S_30,CKV_K8S_11,CKV_K8S_12,CKV_K8S_28 to enforce only the critical controls as blocking, while reporting (but not blocking on) lower-severity findings. This prevents teams from ignoring critical issues among a large list of informational findings, and allows a gradual tightening of the gate over time by adding check IDs to the blocking list as remediation progresses.
Secrets and supply chain: values.yaml hygiene and chart signing
Two Helm-specific security risks that static analysis tools often miss are secrets in values files and supply chain tampering of third-party charts. Values files that contain database passwords, API keys, or TLS certificates in plaintext are committed to version control as part of the chart, making secret exposure a repository access problem rather than an application security problem. Third-party Helm charts from public repositories can be modified between publication and installation if provenance verification is not enforced. Both risks require specific controls beyond the manifest-scanning tools.
Replace plaintext secrets in values.yaml with SOPS-encrypted values using the helm-secrets plugin
Install helm-secrets with helm plugin install https://github.com/jkroepke/helm-secrets and configure SOPS with an AWS KMS or GCP KMS key as the encryption backend. Encrypt the secrets values file with helm secrets encrypt values-secrets.yaml which produces values-secrets.yaml.dec as the decrypted plaintext (gitignored) and stores the encrypted version in the repository. Deploy with helm secrets install my-release ./chart -f values.yaml -f secrets://values-secrets.yaml which decrypts at deploy time using the KMS key without the plaintext ever appearing in the repository, shell history, or CI/CD logs. This eliminates the most common Helm secret exposure path while maintaining a workflow that is not significantly more complex than plain values files.
Audit third-party Helm chart dependencies with helm dependency list and check for unverified chart repositories
Run helm dependency list ./my-chart to see all chart dependencies including their repository source and version. For each dependency, verify that the chart repository is official or organizationally approved rather than an unofficial mirror, that the chart version is pinned to a specific version string rather than a range, and that the dependency chart has been reviewed by someone in the organization rather than blindly trusted. Add helm dependency update with subsequent Checkov scanning of the downloaded dependency charts to the CI/CD pipeline so that security properties of dependency charts are checked automatically when they are updated. Third-party charts like community-maintained database operators and ingress controllers regularly ship with settings optimized for quick deployment rather than security.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
The bottom line
Helm chart security scanning with Checkov and Kubesec catches the misconfigurations that Helm's own validation ignores: containers running as root, missing resource limits, hostNetwork access, and secrets in values files. Render the chart with production values before scanning to test what will actually be deployed, configure Checkov to fail the pipeline on critical check IDs (CKV_K8S_30 for root user, CKV_K8S_11 and CKV_K8S_12 for resource limits), use Kubesec for a numeric risk score gate, replace plaintext secrets in values.yaml with helm-secrets and SOPS, and enforce signature verification on third-party charts. The first scan of a production chart typically surfaces a dozen findings; remediating them takes a day and eliminates the container escape and resource exhaustion paths that make Kubernetes workload compromise a lateral movement stepping stone.
Frequently asked questions
How do I scan a Helm chart with Checkov before deploying?
Scan a Helm chart directory directly with Checkov using checkov -d ./my-chart --framework helm, which renders the chart templates with default values and evaluates the rendered Kubernetes manifests against Checkov's Kubernetes policy library. Checkov runs 80+ checks against the rendered output including CKV_K8S_30 (do not run as root), CKV_K8S_11 (CPU limits set), CKV_K8S_12 (memory limits set), CKV_K8S_8 (liveness probe configured), and CKV_K8S_28 (do not use host network). To test with non-default values, pass the values file with --var-file ./values-production.yaml so the scan reflects the actual configuration that will be deployed rather than chart defaults. Run checkov -d ./my-chart --framework helm --output json to get machine-readable output suitable for CI/CD pipeline parsing and threshold enforcement.
How do I integrate Helm chart security scanning into a GitHub Actions pipeline?
Integrate Helm security scanning into GitHub Actions by adding a dedicated scan job that runs before the deploy job in the workflow. Add a step using the Checkov GitHub Action: uses: bridgecrewio/checkov-action@master with parameters directory: helm/my-chart and framework: helm. Add a second step using Kubesec: run helm template ./helm/my-chart | kubesec scan - then fail the step if the score is below the threshold using exit code checking. Configure the deploy job with needs: [helm-security-scan] so deployment is blocked if the scan job fails. Add a soft-fail option during the initial rollout period (checkov with --soft-fail) to surface findings without breaking the pipeline, then remove soft-fail after remediating existing chart issues. Store baseline scan results as CI artifacts for audit evidence.
How do I detect secrets hardcoded in Helm values.yaml files?
Detect hardcoded secrets in Helm values files using a combination of static analysis and pre-commit hooks. In CI/CD, run truffleHog on the chart directory: truffleHog filesystem ./my-chart --include-paths='*.yaml,*.yml,*.json' to detect high-entropy strings and regex-matched patterns (API keys, passwords, connection strings, private keys). Run detect-secrets scan ./my-chart --baseline .secrets.baseline to maintain a tracked baseline of approved false positives while catching new additions. For pre-commit enforcement, add detect-secrets-hook to .pre-commit-config.yaml so developers cannot commit values files with secrets. For the legitimate requirement of secret values in Helm deployments, use the helm-secrets plugin with SOPS backend: helm secrets encrypt values-production.yaml encrypts the file using KMS or PGP, and helm secrets install my-release ./chart -f secrets://values-production.yaml decrypts at deploy time without the plaintext ever living in the repository.
What are the most critical Helm chart security misconfigurations to fix?
The highest-risk Helm chart misconfigurations in order of exploitability: containers running as root (set securityContext.runAsNonRoot: true and runAsUser: 1000 or higher in the deployment template), no read-only root filesystem (set securityContext.readOnlyRootFilesystem: true and add emptyDir volumes for writable paths like /tmp), missing resource limits (an unlimited container can exhaust node resources, set resources.limits.cpu and resources.limits.memory for every container), containers with hostNetwork: true or hostPID: true (these break namespace isolation and allow the container to see all host network traffic and processes), and containers with capabilities beyond the default set (add securityContext.capabilities.drop: [ALL] and add only the specific capabilities required). Fix these five categories and a Kubesec scan that previously scored negative will typically reach a passing score of 4-6.
How do I use Kubesec to score Helm chart security?
Use Kubesec to score Helm chart security by first rendering the chart to a manifest file and then scanning the rendered output. Render the chart with helm template ./my-chart -f values-production.yaml > rendered-manifest.yaml, then scan with kubesec scan rendered-manifest.yaml. Kubesec returns a JSON score where positive values indicate security controls implemented (read-only root filesystem earns +1, non-root user earns +1, CPU and memory limits earn +1 each, dropped capabilities earn +1) and critical negatives flag dangerous configurations (privileged container is -1, hostPID is -1, NET_ADMIN capability is -1). A score below 0 means the chart has critical risks that outweigh its security controls. Set the CI/CD pipeline to fail if the Kubesec score is below your minimum threshold: parse the JSON output score field and compare it against the minimum score in the pipeline script before allowing deployment.
How does Helm chart signing and provenance verification work?
Helm chart signing provides cryptographic verification that a chart has not been tampered with between publication and deployment. To sign a chart, create a GPG key pair and configure Helm to use it: helm package --sign --key 'mykey@example.com' --keyring ~/.gnupg/secring.gpg ./my-chart which creates both the .tgz chart archive and a .prov provenance file containing the chart's SHA256 hash signed with the private key. Publish both files to the chart repository. To verify on install, use helm install --verify my-release my-repo/my-chart which checks that the provenance file signature validates against a trusted public key in the keyring and that the chart archive hash matches the hash in the provenance file. In CI/CD, enforce signature verification by adding --verify to all helm install and helm upgrade commands and ensuring the public key of the trusted chart publisher is in the cluster's keyring. Chart signing is particularly important for third-party charts from public repositories where supply chain tampering is a realistic risk.
How do I enforce Helm chart security policies using OPA Gatekeeper?
Enforce Helm chart security policies at the cluster admission layer using OPA Gatekeeper, which intercepts every Kubernetes resource creation request and evaluates it against defined constraint policies before allowing it into the cluster. Install Gatekeeper with helm install gatekeeper gatekeeper/gatekeeper --namespace gatekeeper-system. Define a ConstraintTemplate that validates the security context: create a template that checks for runAsNonRoot: true and readOnlyRootFilesystem: true in pod specs, then create a Constraint resource that applies the template to all namespaces except kube-system. Gatekeeper operates as an admission webhook, so even if a Helm chart is deployed without the security context set, Gatekeeper will reject the deployment request before any pods are created. This provides a last-line defense that catches charts that were deployed without going through the CI/CD security scanning pipeline, such as manual kubectl apply or direct helm install commands.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.