How should teams publish Helm charts from a Git repository so they can be discovered through a static registry?

Teams should store the chart source in a public repository, package the charts under a predictable directory structure, and use a release process that generates an index file for the repository. Hosting the rendered repository on a static site such as GitHub Pages lets Helm clients treat it as a registry, while Artifact Hub can index it for discovery.

How the static registry pattern works

Helm can consume a Git-hosted repository when that repository exposes the two things a chart client expects: packaged chart artifacts and an index file that describes them. The practical pattern is to treat a public Git repository as the source of truth, then publish the generated repository contents to a static site so Helm and catalog tools can read it without a backend service.

The key design choice is separation of source and distribution. Keep chart source files in Git, but publish the rendered output, typically the packaged .tgz files and index.yaml, to a stable static location. That makes the repository easy to clone, easy to review, and easy for consumers to fetch with ordinary HTTP access.

This is a good fit for teams that want low operational overhead and predictable release mechanics. It also makes discovery easier when the same published endpoint can be indexed by a catalog such as Artifact Hub, which reads repository metadata rather than requiring direct access to the source tree.

Repository layout and release flow that keep Helm happy

A predictable directory structure matters because Helm chart repositories are conventionally organized around chart names, versions, and release artifacts. If teams scatter charts across ad hoc paths, automation gets harder: release jobs cannot reliably package, index, and publish the right files, and consumers struggle to understand what is authoritative.

In practice, the flow is usually: commit chart source to Git, package each release, generate or update the index, then publish the rendered output to the static site. For a public repository, that site can be a Git-hosted pages endpoint, which gives you a durable read-only distribution layer while preserving version history in Git.

When you want a concrete example of what can go wrong with exposed repository content and metadata, NHIMG’s Emerald Whale breach and CI/CD pipeline exploitation case study both show how repository and pipeline mismanagement can turn routine publication steps into secret-exposure problems.

Discovery, trust, and what teams should verify before publishing

Static publication is simple, but teams still need to verify that what gets indexed is exactly what they intend to ship. The published repository should contain only release-ready chart artifacts, a correct index, and any auxiliary metadata that the registry consumer needs. If the release job publishes unreviewed files, stale versions, or sensitive materials, the static nature of the site makes those mistakes widely accessible.

Teams should also check that the chart archive names, version fields, and index entries stay aligned. A mismatch between the packaged artifact and the index can make discovery unreliable, even if the site itself is reachable. For public registries, that consistency is important because consumers may trust search results or catalog listings before they inspect the repository directly.

For broader identity and secrets hygiene around repository publishing, NHIMG’s NHI Lifecycle Management Guide is useful for understanding how release automation, credential handling, and offboarding discipline affect the safety of a publishing workflow.

Risk and Threat Considerations

Publishing charts from Git is operationally convenient, but the same mechanism can expose source, metadata, or embedded secrets if packaging and release controls are weak. The main failure mode is not the static registry itself, it is letting the static publishing step carry forward anything that should have stayed in source control or a protected secret store.

Failure mechanism: A build or release job packages chart content from a repository that contains hardcoded credentials, stale artifacts, or misnamed versions, then publishes that material to a public static endpoint where it is immediately discoverable.

Impact: Consumers may deploy untrusted or incorrect chart versions, and exposed credentials or pipeline metadata can widen the blast radius beyond the Helm repository itself. In practical terms, repository publication becomes both a distribution channel and a potential leak channel.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS Control 3 — Data Protection	Chart repos can expose secrets or sensitive metadata if published incorrectly.
	CIS Control 4 — Secure Configuration of Enterprise Assets and Software	Helm publishing depends on consistent packaging, indexing, and release configuration.
	CIS Control 16 — Application Software Security	The release workflow is a software delivery path that can introduce insecure artifacts.
Recommendation — Scan chart content before publication and prevent sensitive material from reaching the static registry. Standardize chart packaging and repository publication settings before generating the index. Build and publish charts through a controlled release pipeline with review and validation gates.
NIST CSF 2.0	PR.DS — Data Security	Published chart repositories must avoid exposing embedded secrets or sensitive release data.
	PR.IP — Information Protection Processes and Procedures	The workflow needs repeatable packaging, indexing, and publication procedures.
	PR.AC — Identity Management, Authentication and Access Control	Repository publishing and release access should be limited to approved automation and maintainers.
Recommendation — Protect chart artifacts and repository contents so only intended files are publicly accessible. Document and automate the chart packaging and static publishing process. Restrict who can publish the rendered repository and update release artifacts.
OWASP Non-Human Identity Top 10	NHI-01 — Secrets and Credential Exposure	Public chart repositories can leak embedded secrets if release inputs are not sanitized.
	NHI-03 — Privilege and Access Misconfiguration	Publishing automation and repository access can create excessive exposure if misconfigured.
	NHI-06 — Lifecycle and Rotation Gaps	Release pipelines often use credentials that must be rotated and retired cleanly.
Recommendation — Remove secrets from chart sources and validate artifacts before publishing. Limit publishing credentials and repository permissions to the minimum required. Rotate publishing credentials and revoke any unused release access paths.

Practitioner Guidance

What to verify: Confirm that the published endpoint contains only packaged charts and the generated index, and that the source repository does not rely on manual edits to the rendered output. If humans can bypass the release job, the static registry becomes harder to trust than the source tree it was meant to simplify.

Implementation sequence: First standardize chart paths and naming, then automate packaging and index generation, then publish the rendered output to a static host, and only after that connect discovery tooling. This sequence reduces the chance that catalog visibility outruns release discipline.

Practitioner takeaway: Treat the static registry as a publish artifact, not as the system of record, because the quality of discovery depends on release integrity more than on where the files are hosted.