Bazel vendor mode makes a local copy of your external dependencies so builds can run offline and you control the source of each one. It improves control and review, but it does not make the code safe, and the vendored copy needs re-vendoring when inputs change.
What it is
Vendor mode is a Bazel feature that creates a local copy of external dependencies. The documentation says it is useful for offline builds, or when you want to control the source of an external dependency. You turn it on with a vendor directory setting in your rc file, then populate it with the vendor command.
The commands
# .bazelrc
common --vendor_dir=vendor_src
# vendor one repository
bazel vendor --vendor_dir=vendor_src --repo=@rules_cc
# vendor what given targets need
bazel vendor --vendor_dir=vendor_src //src/main:hello-world
# build offline afterwards
bazel build --vendor_dir=vendor_src //src/main:hello-world
The docs say the offline build should work in a clean environment with no network access and no repository cache, and that you can check in the vendored source and build the same targets on another machine.
What you gain
- Reviewability: the bytes are in your repository, so a diff shows exactly what changed in a dependency update.
- Availability: registry or host outages stop mattering for builds.
- Tamper resistance after the fact: a later change at the upstream URL cannot reach you silently.
What it costs
- Repository size grows. Vendoring everything in the transitive graph can be large and slow, and some repositories fail to fetch on an incompatible platform, so the docs suggest starting with specific targets.
- You must re-vendor after changes to targets, dependencies, build configuration or the Bazel version.
- Updates become pull requests. That is a feature if reviewers actually read them.
A decision guide
| Your situation | Vendor? |
|---|---|
| Air gapped or regulated build environment | Yes |
| Need to audit every dependency change | Yes, for the targets that ship |
| Small team, fast moving, registry access reliable | Probably a lockfile and checksums are enough |
| Huge transitive graph | Vendor for release targets only |
Pinning inside the vendor directory
A VENDOR.bazel file under the vendor directory supports an ignore directive, which excludes a repository from vendor mode, and a pin directive, which pins a repository to its current vendored source as if it had an override. Pin carefully, because a pinned repo stops following upstream.
What still needs doing
Vendored code still needs scanning. Bazel has a lockfile dependencies option for vendoring what a lockfile update needs, which is useful if you want tidy to run with fetching disabled.
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
Click through the inventory to see what a vendored tree would contain, then scan it like any other source.
Click through it at your own pace, or open it full screen.
Quick check
Does vendoring make a dependency trustworthy?
No. It makes the code stable and reviewable. A malicious version vendored today is still malicious.
Should I vendor every dependency?
The docs warn this can be slow and large. Consider vendoring the dependencies of your release targets first.
Sources
Last reviewed: 19 October 2026.
