A Helm chart SBOM should list three things: the chart itself with its version, the subcharts it depends on, and the container images it deploys. The chart metadata covers the first two. The images are named in templates and values, so you must resolve them separately.
What chart metadata tells you
The Helm documentation describes Chart.yaml. It includes a dependencies field, a list of chart requirements where each entry has a name, a version and a repository, plus optional conditions and tags. It also includes an appVersion field, described as the version of the app that the chart contains, which need not be semantic versioning and is informational, with no impact on chart version calculations.
Two consequences follow:
- version and appVersion are different things. The chart version describes the packaging. appVersion describes the application it deploys. An SBOM should record the chart version as the component version, and treat appVersion as a hint.
- Dependencies are charts, not images. A subchart is a component, but it brings its own images, so the list is not complete until you look inside.
Where the images hide
Container images are usually named in values files and templates, and the final reference can change with the values you supply at install time. So a chart SBOM generated from metadata alone cannot know which images will run.
| Layer | Source | Notes |
|---|---|---|
| The chart | Chart.yaml name and version | Your own component |
| Subcharts | The dependencies field | Pin exact versions |
| Images | Rendered templates | Depend on the values used |
| Image contents | A scan of each image | Gives the packages inside |
Steps
- Pin chart dependencies to exact versions and keep the lock information with the chart.
- Render the chart with the values you ship, such as production defaults.
- Extract every image reference from the rendered output. Record each by digest where you can, not only by tag.
- Generate an SBOM for each image and link it to the chart SBOM.
- Build the chart SBOM with the chart, subcharts and image references as components, and relationships between them.
- Repeat for each environment whose values differ.
Mistakes to avoid
- Tags without digests. A tag can change after you generate the SBOM.
- Skipping hooks and jobs. Init containers and one off jobs may reference additional images.
- Ignoring values overrides. The image that runs is the one after overrides, not the default.
- Forgetting the chart's own provenance. Note where the chart was pulled from.
Who asks for this
Platform teams that install third party charts want to know what they are about to run. Vendors who distribute charts to customers are asked to supply it. Either way, being able to answer "which images does this chart run, and what is in them?" is more useful than a chart level list alone.
Where Safeguard fits
Safeguard scans container images and produces SBOM and dependency results, so you can run each image from a rendered chart through the free scan at gold.safeguard.sh/scan. Confirm chart specific features with your account contact.
Quick check
Is appVersion the version to put in the SBOM?
No. Use the chart version for the chart component. appVersion is informational.
Why render the chart first?
Image names are resolved after values are applied, so only the rendered output shows what will really run.
Sources
Last reviewed: 19 October 2026.
