Edit the version range for the subchart in Chart.yaml, then run helm dependency update. Helm downloads the newest chart that satisfies the range, cleans up old copies, and writes a lock file. Commit the lock file so everyone rebuilds the exact same dependency set.
What the command does
The Helm documentation says helm dependency update updates the on-disk dependencies to mirror Chart.yaml. It verifies that the required charts are present in the charts directory and at an acceptable version, pulls down the latest charts that satisfy the dependencies, and cleans up old ones. On success it generates a lock file that can be used to rebuild the dependencies to an exact version.
There is a caveat in the same text. Dependencies are not required to be represented in Chart.yaml, so an update will not remove charts unless they are both present in Chart.yaml and at the wrong version. A stray chart in the charts directory can therefore linger.
Steps for a security bump
- Identify the chart dependency and the fixed chart version.
- Edit its version constraint in Chart.yaml to admit the fix, keeping the range as narrow as is practical.
- Run helm dependency update on the chart.
- Inspect the diff: Chart.lock and, if you commit packaged charts, the charts directory.
- Render the templates and diff them against the previous render. Resource changes, new values, or renamed keys show up here.
- Install into a test namespace and check the workloads start.
- Commit Chart.yaml and the lock file together.
helm dependency update ./mychart
helm template mychart ./mychart > after.yaml
Range or exact version
| Constraint style | Behavior on update | Good for |
|---|---|---|
| Exact version | Moves only when you edit it | Predictable security bumps |
| Range | Picks the newest match at update time | Staying current, with the lock file as the record |
With a range, the lock file is what makes builds repeatable. Without it, two people running an update a week apart can get different subcharts. Treat the lock file as a reviewed artifact, not noise.
What to review in the render
A subchart bump can change more than an image tag. Look for changed default values, new containers, altered security contexts, new network policies, and removed resources. Values you override in the parent chart can silently stop applying if the subchart renamed a key, so also compare the parent's values against the subchart's new defaults.
A passing render is not a passing deployment, so run a staged rollout. If the subchart is a database or a gateway, take the usual backup first and plan the rollback before you install. The guide on rolling back a bad dependency upgrade merge applies here too.
Container images inside the chart
A chart dependency bump and an image bump are different things. The chart may reference an image tag you can override. Scan the images that the rendered manifests actually reference, not just the chart metadata.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how image findings are listed, since a subchart bump often changes which images you run.
Where Safeguard fits
Safeguard scans dependencies, runs reachability analysis to show which findings your code can actually reach, and can open fix pull requests through autonomous remediation. That last feature is off by default and every category starts on Manual, so a person approves each change. You can try a free scan on a repository first.
Quick check
What does the Helm lock file do?
It records the exact chart versions so dependencies can be rebuilt to the same versions.
Will helm dependency update remove any chart in the charts folder?
No. It does not remove charts unless they are in Chart.yaml and at the wrong version.
Sources
Last reviewed: 19 October 2026.
