SAN FRANCISCO — July 6, 2026. Kubernetes Helm charts have quietly become one of the least-scrutinized links in the cloud-native supply chain, and new analysis from Safeguard's research team suggests the gap is widening rather than closing. Reviewing a representative sample of publicly listed charts on Artifact Hub and comparing configurations against CIS Kubernetes Benchmark controls and known-vulnerable image tags, Safeguard found that roughly 68% of charts still default to running containers without a defined non-root user, 41% ship RBAC bindings broader than the workload requires, and nearly 1 in 4 pin subchart or container image dependencies to tags that resolve to versions carrying at least one high or critical CVE at install time. None of this requires a misconfigured cluster or a careless operator — it's baked into the chart as published, waiting for helm install to propagate it downstream.
The finding matters because Helm's adoption curve has outpaced its security tooling curve. Helm is now the default packaging format for a large share of production Kubernetes deployments, and Artifact Hub alone indexes tens of thousands of charts spanning official vendor releases, community forks, and one-off internal projects pushed public by mistake. Every one of those charts is a template that gets rendered, trusted, and applied — often with --set overrides that never touch the risky defaults buried three levels deep in values.yaml.
The Shape of the Problem
Helm charts sit at an unusual intersection in the software supply chain: they are simultaneously configuration, dependency manifest, and deployment artifact. A single Chart.yaml can declare subchart dependencies that pull in their own container images, their own RBAC requirements, and their own default resource policies — and Helm's dependency resolution will happily walk several layers deep without surfacing what changed. That structure creates three compounding risk categories that Safeguard's data shows recurring across chart repositories:
Inherited image risk. Charts frequently pin base or sidecar images (Redis, Postgres, NGINX ingress controllers, cert-manager, logging sidecars) to tags that were current when the chart was authored but have since accumulated CVEs. Because the chart author, not the installing team, chooses the tag, the vulnerability is inherited silently. Safeguard's sample found the median chart had not bumped a pinned image tag in over 200 days.
Over-permissioned defaults. To minimize support tickets, many chart maintainers default to permissive ClusterRole bindings, hostNetwork: true, or privileged: true rather than scoping access tightly and documenting the narrower path. This trades security for "it just works," and in practice very few adopters revisit the RBAC section before deploying.
Secret sprawl in values files. Despite years of guidance against it, default values.yaml files still frequently include placeholder credentials, API tokens, or connection strings that get committed into GitOps repos verbatim when teams copy the chart into their own config management without stripping example secrets.
What the Numbers Show Year Over Year
Comparing chart snapshots pulled at intervals over the past 18 months, several trends stand out:
- Dependency depth is increasing. The average number of transitive subchart dependencies per published chart has grown as ecosystems like observability stacks (Prometheus, Grafana, OpenTelemetry collectors) and service mesh tooling get bundled together for convenience. More depth means more places for a stale or vulnerable image to hide.
- Time-to-patch is lagging behind upstream image fixes. When an upstream base image publisher ships a patched release, Safeguard's tracking shows a median lag of two to four weeks before popular charts bump their default tag to match — and a long tail of charts that never update the pin at all until a maintainer manually intervenes.
- Fork proliferation is diluting provenance. Popular charts are frequently forked and re-published with minor modifications, and forks inherit the vulnerabilities of the chart they were copied from at the moment of the fork, then drift further from any subsequent upstream security fix.
- CI/CD auto-upgrade paths remain rare. Very few organizations have automated tooling that re-evaluates a chart's transitive dependencies on every deploy; most treat
helm upgradeas a version bump exercise rather than a security gate.
Why This Is a Supply Chain Problem, Not a Config Problem
It's tempting to file Helm chart risk under "misconfiguration" and move on, but that undersells the supply chain dimension. A chart is code that gets pulled from a registry, executed by a templating engine, and trusted to define what runs with what privileges — the same trust model that makes npm packages, container base images, and CI actions supply chain risks. The difference is that Helm charts have received comparatively little attention from the scanning ecosystem relative to package registries and base images. Most container scanning pipelines evaluate the image that ends up running, but many teams never scan the chart itself — the RBAC bindings, network policies, and dependency graph declared in the chart's templates — before it ever reaches a cluster.
This is exactly the kind of gap attackers look for: a place where trust is assumed and verification is thin. A poisoned or stale chart doesn't need to exploit a zero-day; it just needs to be installed as-is, which is precisely what most helm install and helm upgrade workflows do by default.
The Exposure Multiplier: Reachability Matters More Than Raw CVE Counts
Not every CVE embedded in a chart's dependency tree is equally dangerous, and this is where a large share of security teams overspend their attention. A critical CVE in a logging sidecar that never receives external traffic and runs with minimal filesystem access poses a materially different risk than the same CVSS score attached to an internet-facing ingress controller with a writable service account token mounted. Vulnerability counts alone — the metric most scanners still lead with — don't distinguish between the two. Teams chasing raw CVE volume across hundreds of charts end up triaging noise instead of the handful of paths that are actually exploitable given how the workload is deployed, what it's exposed to, and what permissions it holds.
What Security and Platform Teams Should Be Doing Now
Based on the patterns above, a few practical shifts stand out for teams managing Helm-based deployments at scale:
- Scan charts before rendering them, not just the images that result from
helm template. RBAC, network policy, and pod security context issues live in the chart templates themselves. - Pin and verify subchart dependency versions explicitly rather than trusting whatever the chart author last committed — and re-check those pins on a cadence, not just at initial adoption.
- Strip and rotate any example secrets in
values.yamlbefore charts ever reach a GitOps repository. - Prioritize remediation by reachability and exposure, not CVE count — a chart with fewer but exploitable, internet-facing issues deserves attention before one with many CVEs buried in unreachable internal services.
- Generate and retain an SBOM for every chart deployment, so that when an upstream image or dependency is later found vulnerable, teams can identify affected deployments in minutes rather than re-auditing every cluster from scratch.
How Safeguard Helps
Safeguard is built to close exactly this gap between what a Helm chart declares and what actually ends up exposed at runtime. Our platform ingests and generates SBOMs across chart dependencies, container images, and rendered manifests, giving teams a single, continuously updated inventory of every component a chart pulls in — including transitive subchart dependencies that traditional scanners miss. Griffin AI, Safeguard's reasoning engine, applies reachability analysis to each identified vulnerability so teams can see which CVEs sit on an actual exploitable path — internet-facing, privileged, or credential-bearing — versus which are dormant in code that never executes in the deployed configuration. When a fix is available, Safeguard can open an auto-fix pull request that bumps the vulnerable image tag or corrects an over-permissioned RBAC binding directly in the chart source, so remediation happens in the repository instead of as a manual follow-up ticket. The result is a workflow where chart risk is triaged by real-world exploitability rather than raw CVE volume, and where fixes ship as fast as the vulnerabilities are found.