Yes. Bazel's documentation says module extensions can perform file I/O and send network requests as part of resolution. They are code that runs before your build, so review them like install scripts: what they fetch, whether downloads are checksummed, and what they read from the environment.
What an extension is
A module extension lets a module generate repositories programmatically, for example from a list of packages or a toolchain description. Extensions are written in Starlark and run during module resolution. They are powerful, which is why they are the part of the module system that deserves the closest reading.
Where the lockfile helps
The lockfile records, for each extension, a digest of the implementation and the files it loads, a digest of its usages, other tracked inputs such as files it reads and environment variables it uses, and the repositories it generated. A change in any of those shows up in the lockfile diff. That gives reviewers a place to notice an extension that suddenly generates different repositories.
An extension can opt out of the lockfile by returning metadata marked reproducible. By doing so it promises it always creates the same repositories for the same inputs. Treat that promise as something to verify, not accept.
Review checklist
| Question | Why it matters |
|---|---|
| Does it download anything? | Network at resolution time is a moving input |
| Is every download guarded by a checksum? | Unguarded downloads can change between runs |
| What environment variables does it read? | Hidden configuration, possible secrets exposure |
| Does it execute external programs? | Arbitrary processing at fetch time |
| Is it marked reproducible? | It then skips the lockfile, so rely on your own review |
| Who maintains it? | A maintainer change is a risk event |
The extension documentation also describes a facts parameter for cases where something is fetched without an available checksum: facts are persisted in the lockfile, so a later change is visible.
Extensions you did not write
Extensions in your dependencies run too, including extensions used only by dependencies. The documentation for updating the lockfile notes that doing so evaluates every module extension in the dependency graph, so a transitive extension executes on a maintainer's machine when they run tidy or deps.
Practical steps:
- List extensions used across the graph, using the mod command's extension view.
- Review the ones you own and the ones from small or unfamiliar modules.
- Run lockfile updates in a clean, low privilege environment, not on a laptop with cloud credentials loaded.
- Fail CI on lockfile drift so an extension change cannot slip through.
Where Safeguard fits
Safeguard can inventory the dependencies your repository declares through SBOM and dependency scanning, and reachability analysis helps you decide which findings matter first. You can try a free scan on a repository to see what it finds. Check coverage for your specific build files before relying on it.
Try it yourself
Open the policy gate demo and see how a rule can block a change until a person has reviewed it, the same pattern you want for a lockfile diff that touches an extension.
Click through it at your own pace, or open it full screen.
Quick check
Are extensions in my dependencies executed too?
Yes. Updating the lockfile evaluates every extension in the graph, including ones used only by dependencies.
Is a reproducible extension safe?
Reproducible only means it promises the same output for the same input. It says nothing about whether that output is trustworthy.
Sources
- Bazel documentation: Module extensions
- Bazel documentation: Bazel lockfile
- Bazel documentation: Vendor mode
Last reviewed: 19 October 2026.
