Should you vendor your dependencies into your repository?

Vendoring, which means committing a copy of your dependencies into your own repository, makes builds independent of the registry and makes every change visible in review. It also makes updates and security scanning your job. It suits teams that value control and can keep up the upkeep.

What you gain

1. Registry independence. A removed, yanked or unavailable version cannot break your build, and a registry outage cannot stop a release.
2. Visible changes. Each update arrives as a diff in a pull request. Reviewers can read what changed, including unexpected files.
3. Offline and air gapped builds. The source is already on hand.
4. A fixed record. The repo history shows exactly what was built from.

What it costs

1. Repository size and noise. Large diffs bury real changes. Reviewers skim, and skimming defeats the point.
2. Update work. Nothing updates itself. Security fixes reach you only when someone pulls them in.
3. Scanning must read the vendored copy. Tools that read only manifests may miss code that was copied in without metadata, or see an old version.
4. Local edits. It is tempting to patch a vendored file. Undocumented patches make later upgrades risky and hide divergence from upstream.
5. License duties. Copied source carries its license with it. You must keep notices intact.

Decision guide

Vendoring tends to fit when:

• you build in restricted or offline environments,
• you must prove what source went into a release,
• you have few, stable dependencies, or
• you have a reviewer culture that reads dependency diffs.

A lockfile with hash verification and a private mirror tends to fit when:

• you have hundreds of transitive dependencies,
• you update often,
• you want automatic update proposals, or
• your team is small and review time is scarce.

Many teams choose the second option: a lockfile, a mirror that caches approved versions, and scanning in CI.

If you do vendor

1. Record the upstream version and source for each vendored item in a file the scanner can read.
2. Commit vendored code in its own commits, apart from your changes.
3. Forbid edits in the vendor directory, or require a patch file with a reason.
4. Add a scheduled job that compares vendored versions with the latest upstream and with advisory data.
5. Verify the vendored files against upstream checksums when you update.
6. Make sure your scanner and SBOM generator include the vendored tree.

If you do not vendor

Pin with hashes, install from a lockfile, mirror to a controlled proxy and keep build logs long enough to answer exposure questions later.

Either way

Know what is in your software. Safeguard produces SBOMs and scans dependencies, including from manifests and lockfiles, which gives you an inventory whichever approach you choose. Check that any tool you use sees your vendored directories.

Quick check

Last reviewed: 19 October 2026.