Partly. A condition or tag stops Helm from loading a subchart, so its resources are not installed. But the dependency is still declared in Chart.yaml, and helm dependency update still downloads its archive into charts/. It remains in your repository, your build, and any scan of those files.
What the documentation says
The Helm documentation explains that all charts in dependencies are loaded by default. If tags or condition fields are present, Helm evaluates them to control loading. A condition holds one or more YAML paths. If the path exists in the top parent's values and resolves to a boolean, the chart is enabled or disabled by that value. Only the first valid path is evaluated, and if none exist, the condition has no effect.
Tags group charts so one value can switch several. Conditions set in values always override tags, per the docs. And tags and conditions must be set in the top parent's values, with tags as a top level key. Nested tag tables and globals are not currently supported for tags.
What a disabled subchart still leaves behind
When you run helm dependency update, Helm downloads each chart listed under dependencies and stores it as an archive in the charts directory. The documentation example shows files such as apache and mysql archives appearing there. Nothing in the description says a disabled condition skips that download.
So a disabled subchart can still:
- Sit in charts/ as a packaged archive you may commit or publish.
- Appear in a dependency listing or software bill of materials built from Chart.yaml.
- Trigger scanner findings if your scanner reads the dependency list rather than the rendered manifests.
- Come back to life if someone sets the condition to true, or if a default changes.
That last point matters most. A switch in a values file is a runtime decision made by whoever installs the chart.
Default on, not default off
Because all charts load by default, a missing condition path means the subchart is enabled. A typo in the path, or setting it in the wrong place, silently leaves the subchart on. The docs say a condition with no matching path has no effect. Check by rendering, not by reading the values.
How to prune safely
- Render the chart with your production values and list the resources produced. Confirm the disabled subchart contributes none.
- If you never need it, remove it from dependencies instead of disabling it. Less declared means less to patch.
- If you do need it for some installs, keep the condition, but add a values schema that documents and restricts the switch. See can values.schema.json stop risky Helm settings.
- Pin the dependency version, so the archive that stays in your repository is a known one.
- Add a CI check that fails if a disabled dependency has no owner or no review date.
Reading scan results correctly
If a scanner reports a finding in a disabled subchart, ask whether it is reachable in your deployment. A finding in something that is never installed is lower priority than one in a running workload, but it is not nothing, since another environment may enable it. Record the decision, with the condition value and date, so the next reviewer does not redo the analysis.
Reachability analysis, which Safeguard offers, helps separate code that runs from code that merely ships. Safeguard's SBOM and dependency scanning can list the declared dependencies, and policy gates can require that unused subcharts are removed or justified. Check how your scanner treats Helm conditions. Free scan: gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
See how separating reachable from unreachable findings changes what you fix first.
Quick check
Are subcharts enabled by default?
Yes. The Helm documentation says all charts are loaded by default, and tags or conditions only control loading when present.
Do conditions beat tags?
Yes. The documentation says conditions set in values always override tags, and the first valid condition path wins.
Sources
Last reviewed: 19 October 2026.
