Vendor dependencies when you need builds that work offline or must survive a registry outage, and when you can afford to review and update the copied code. Otherwise a committed lockfile plus a private cache gives most of the benefit with less repository weight.
What vendoring means
Vendoring is keeping a copy of your dependencies inside your source tree, or referencing a fixed copy through something like git submodules. The reproducible-builds project lists it, next to lockfiles and distribution snapshots, as one way to prevent dependency drift. Its commandments go further and say a build should allow offline builds, because servers can be down and contents can change.
Three ways to freeze dependencies
| Approach | What you store | Offline build | Review effort |
|---|---|---|---|
| Lockfile only | Names, versions and hashes | No, needs a registry | Low |
| Lockfile plus internal cache or mirror | Same, plus a copy held by you | Yes, from the mirror | Medium |
| Vendored source in the repo | The code itself | Yes | High |
A lockfile records exact versions, but it does not keep the package alive. If a maintainer removes a release or a registry is unreachable, a lockfile alone cannot rebuild. The same project says inputs from the network are volatile even when they do not seem so, and recommends integrity checksums plus backups with a fallback location.
When vendoring earns its cost
- You build in a network-restricted environment.
- You must rebuild an old release years later.
- You ship firmware or desktop software where a rebuild may be needed long after the registry changed.
- You want code review to see dependency changes as ordinary diffs.
When it does not
- Your dependency tree is large and changes weekly. Vendored diffs become noise nobody reads.
- You have no process for updating vendored code. Then the copy ages quietly, which is a security problem of its own.
- You are a library author whose consumers resolve their own versions anyway.
If you do vendor
- Vendor from the lockfile, not from whatever resolves today.
- Record the source version and checksum next to each copied package.
- Keep vendored code in its own directory and exclude it from style linters, but not from vulnerability scanning.
- Schedule updates. A vendored dependency does not receive fixes by itself.
- Check that a clean clone builds with the network disabled, and keep that check in CI.
The scanning catch
Vendored code is easy to forget because it no longer appears as a line in a manifest. Your scanner needs to read either the vendor directory or the lockfile that produced it, otherwise known vulnerabilities in copied code go unseen.
Where Safeguard fits
Safeguard's SBOM and dependency scanning works from manifests and lockfiles, so keep the lockfile that produced a vendor directory in the repo. You can run a free scan at gold.safeguard.sh/scan.
Quick check
Does vendoring remove the need for a lockfile?
No. The lockfile records what was vendored and why, and it lets tools and reviewers see versions without reading source.
Is vendoring the same as caching?
No. A cache holds copies outside your repository and can be rebuilt. Vendored code is part of your source and is reviewed like source.
Sources
Last reviewed: 19 October 2026.
