Before installing a third-party Helm chart, render it locally and read what it would create: container images and their registries, RBAC objects, webhooks, hooks, CRDs, and subchart dependencies. A chart is code that writes cluster objects for you, so it deserves the review you would give an installer script.
A chart is an installer, not a package of data
Helm charts are templates plus defaults. When you run an install, the templates render into Kubernetes objects and the cluster applies them. Anything the chart author put in those templates can end up running with the permissions of the objects they define.
That makes a first install a trust event. You are trusting the chart author, the repository that serves the chart, and every image and subchart the chart references.
What to render and read
Pull the chart without installing it, then render it with your intended values.
helm pull example/some-chart --version 1.2.3 --untar
helm template my-release ./some-chart -f my-values.yaml > rendered.yaml
Then search the rendered file. A short list:
| Look for | Why it matters |
|---|---|
Every image: line | Each is software you will run. Note registry hosts you do not already trust. |
kind: ClusterRole, ClusterRoleBinding | Cluster wide permissions. Check for wildcards. |
ValidatingWebhookConfiguration, MutatingWebhookConfiguration | These sit in the request path of the API server. |
| Helm hook annotations | Hooks run Jobs at install and upgrade, outside the normal release tracking. |
hostPath, hostNetwork, privileged | Node level access. |
| CRDs | Cluster wide API extensions. |
The Helm docs say hook resources are not tracked as part of the release, so uninstalling does not necessarily remove them. Know what yours creates.
Check the chart's own metadata
Open Chart.yaml. Look at the dependencies list: each entry names a repository, and each one is another source you now trust. The Helm documentation says the repository field is the full URL of the chart repository, so you can see exactly where each subchart comes from.
Check for a crds directory. Per the Helm documentation, CRDs there are installed before the rest of the chart, are not upgraded later, and are never deleted by Helm. That is a long lived change to your cluster.
Verify what you can
Helm supports signing and verifying charts with provenance files, but verification only proves the chart was signed by a key you trust and has not changed since. It does not say the contents are safe. Treat it as an integrity check on top of your own reading, not a replacement.
Decide before you install
Write down the answers to three questions and keep them with the pull request that adds the chart.
- Who is the publisher, and how will we learn about security fixes?
- Which images does it pull, and can we mirror or pin them by digest?
- What permissions does it create, and are they narrower than what we would grant by hand?
If you cannot answer the first, the chart has no owner on your side. Name one before it goes in.
Try it yourself
Click through it at your own pace, or open it full screen.
The demo walks through a dependency inventory. Notice how a short list of direct packages expands into a much longer list of indirect ones, which is the same shape as a chart with subcharts and images. Safeguard's dependency scanning and SBOM generation cover the software side of that picture, and you can try a free scan on a project.
Quick check
Is helm lint enough to vet a chart?
No. Lint checks chart structure and some template problems. It does not judge whether the images, permissions or hooks are acceptable for your cluster.
Should I install into a test cluster first?
Yes, when possible. But rendering and reading first is cheaper and tells you what to look for when you do test.
Sources
Last reviewed: 19 October 2026.
