Add a ref query parameter to the remote URL in your kustomization, and use a full commit hash for anything that reaches production. Kustomize documents that ref accepts a branch, tag or full commit hash, and that short hashes are not supported. Without ref, you are trusting whatever the repository serves today.
What a remote base is
A kustomization can list resources that live elsewhere. The kustomize documentation says kustomize build can run on a URL, and that resources can reference other kustomization directories by URL. The URL is an HTTPS or SSH git clone address, with an optional directory and some query parameters.
The directory inside the repository is marked by a double slash after the repository URL. Kustomize clones the repository into a temporary directory and does a clean checkout of the ref, which differs from a plain local path reference, where no Git is involved.
The parameters that matter
| Parameter | Meaning | Note |
|---|---|---|
| ref | A fetchable Git ref | Branch, tag or full commit hash |
| version | Same as ref | Ignored if ref is present |
| timeout | Fetch time limit | Default 27 seconds |
| submodules | Whether to clone submodules | Default true |
Two details have security weight. First, submodules default to true, so a remote base can pull in other repositories without you listing them. Second, the documentation says kustomize does not support ports in the URL, which can matter for self-hosted Git servers.
What each choice means
A URL with no ref follows the repository default. The base can change with any push.
A branch ref follows that branch. Same issue, narrower.
A tag ref is better, but tags can be moved. Use it only if tag protection is on.
A full commit hash cannot change meaning. This is the safest choice, and the documentation's own remote file example uses a raw file URL containing a commit hash.
Remote files work the same way. Resources can reference raw file URLs, and a URL that includes a commit hash in its path is pinned, whereas one that includes a branch name is not.
Legacy URL formats
The documentation says kustomize still supports a modified go-getter style URL format for backwards compatibility, but no longer recommends it, because the query parameters and the meaning of what gets fetched differ, particularly for subdirectories. If your repository uses old-style URLs, migrate them and add a ref while you are there.
A review routine
- Search your repositories for resources entries that start with http, https, ssh or github.com.
- For each, record the repository, the ref and who owns it.
- Replace branches and bare URLs with full commit hashes.
- Set a calendar item or automated pull request to move the hash on purpose.
- Run kustomize build in CI and scan the rendered result. The checkout moves to the commit you pinned, so the output is repeatable.
- Consider turning off submodules for bases that do not need them, or at least review them.
If a base is critical, copy it into your own repository or mirror it, so availability and content are under your control. A pinned hash on a repository that gets deleted still fails your build.
Where a scanner fits
Remote bases are dependencies that do not appear in package lock files. Include them in your inventory by hand, and use dependency scanning and SBOM generation, as Safeguard offers, for the images the rendered manifests reference. Safeguard's pull request gates can hold a change that adds a new remote base. Free scan: gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Look for where remote sources would show up in an inventory like this, and where you would need to add them manually.
Quick check
Can I use a short commit hash in ref?
No. The kustomize documentation says short hashes are not supported. Use the full hash.
What if I give both ref and version?
Kustomize ignores version when ref is provided, according to its documentation.
Sources
Last reviewed: 19 October 2026.
