Treat a Helm plugin like any program you download and run. It is not part of the Helm codebase, it can be written in any language, and it runs with your user's permissions, including access to your kubeconfig. Install plugins from sources you have reviewed, pin the version, and keep the list short.
What a plugin is
The Helm documentation describes a plugin as a tool reached through the helm command that is not part of the built-in Helm codebase. Plugins live in the directory shown by helm env as HELM_PLUGINS. They can be added and removed without touching Helm itself, and they can be written in any programming language.
Each plugin has a plugin.yaml file. Among its fields are the command to run and optional lifecycle commands for install, update and delete. So installing a plugin can execute commands, and so can running it later.
How plugins get installed
The install command accepts a local path or a URL of a remote version control repository. When you install from version control you can name a version. You can also unpack a tarball into the plugins directory by hand, or install a tarball straight from a URL.
Each route has a different trust question:
| Route | What you are trusting |
|---|---|
| Local path | Whoever wrote the files in that folder |
| Repository URL, no version | The tip of the default branch today |
| Repository URL with a version | The ref you named, if it is not moved |
| Tarball URL | The host serving the file, and its integrity |
Without a version, a plugin install takes whatever the repository serves at that moment. That is the same problem as tracking HEAD in a deployment tool.
A short vetting checklist
- Read plugin.yaml first. Note the command, and every install, update and delete command.
- Read the entry point script or binary source. If it downloads more code at run time, find out from where.
- Check the repository for recent activity, a clear owner and a way to report problems.
- Install a named version, not the default branch.
- Record the plugin name, version and source in your repository, next to your CI configuration.
- Run it first on a machine or container that has no production credentials.
The last point matters because plugins often work with cluster access by design. A diff or secrets plugin legitimately needs to read cluster data, so assume a malicious one could read it too.
Plugins in CI
CI is where plugin risk compounds. A plugin installed on a shared runner inherits whatever credentials the job holds. Prefer a pinned container image that already contains the exact plugin versions you approved, rather than installing at the start of every job. Then a change to the toolchain is a reviewed change to an image definition.
Also decide who may add a plugin. If any developer can add an install line to a pipeline, your toolchain is effectively open to anyone with write access.
Where a scanner fits
Plugins rarely appear in application dependency files, so they are easy to miss in an inventory. Keep them in a documented list, and use dependency scanning and SBOM generation, such as Safeguard offers, for the images and packages your pipelines build. Policy gates on pull requests can then flag a pipeline change that adds a new tool. A free scan is at gold.safeguard.sh/scan.
Quick check
Does Helm sandbox plugins?
The documentation does not describe a sandbox for the legacy plugin model. A plugin is an executable launched through helm, so assume it runs with your permissions.
Is a plugin the same as a chart?
No. A chart is a package of Kubernetes templates. A plugin is a tool that extends the helm command, and the documentation says it is only similar to a chart in layout.
Sources
Last reviewed: 19 October 2026.
