Vendor a library, meaning copy its source into your repository, when you need offline or reproducible builds, tight review control, or insulation from a registry. Do not vendor just to avoid updates. Vendored code stops receiving fixes unless you do the work, and scanners may miss it.
What vendoring is
Vendoring stores a copy of a dependency's code in your own repository, usually in a directory such as vendor. Some ecosystems support it directly. In Go, for instance, the go mod vendor command populates a vendor directory and records details in a vendor modules file. In other ecosystems teams copy files by hand or use scripts.
It is different from pinning a version in a lockfile. Pinning still fetches from a registry; vendoring puts the code in your tree.
When it makes sense
| Reason | Why vendoring helps |
|---|---|
| Offline or air-gapped builds | The build needs no registry access |
| Registry independence | A removed or tampered package cannot break or change your build |
| Review control | Changes appear as diffs in your repository, reviewed like your own code |
| Long-lived products | Old releases can be rebuilt years later |
| Patching | You can apply a local fix while waiting for upstream |
When it backfires
- Silent staleness. Nobody sees a new release or advisory, because the copy has no connection to the registry.
- Invisible to scanners. Some tools read lockfiles and manifests; copied files without package metadata may not be matched to a known package and version.
- Repository bloat. Large dependency trees make reviews and clones heavier.
- License duplication. Notices and license files must travel with the code.
- Drift. Local edits make later upgrades painful. See fork maintenance responsibilities.
A safe process
- Vendor using the ecosystem's own tool where one exists, rather than copying by hand, so versions and checksums are recorded.
- Keep the license file and notices with the code.
- Record the upstream name, version and source URL in a manifest next to the vendored folder.
- Generate an SBOM that includes the vendored components, so scanners and auditors can see them.
- Put a scheduled reminder or automated job on the update path. Vendoring without an update routine is how old vulnerabilities live for years.
- Keep local patches as a separate, documented patch file, not edits mixed into the copied source.
Decide with a few questions
- Do we have a reason beyond convenience?
- Who updates it, and how often?
- Will our scanner and SBOM include it?
- Can we explain local changes to a new engineer?
If any answer is "nobody", use a lockfile and a private mirror instead. A mirror gives you registry independence without freezing the code; see building an internal curated package registry.
Where Safeguard fits
Safeguard's SBOM and dependency scanning help you keep an inventory that includes vendored components, and continuous monitoring can flag new advisories against them. Try the free scan at gold.safeguard.sh/scan.
Quick check
Is vendoring more secure than using a registry?
It removes registry risk but adds update risk. It is more secure only if you review and update the copy regularly.
Do vendored libraries need license compliance too?
Yes. Copying code does not change its license terms. Keep notices and review the license as usual.
Sources
Last reviewed: 19 October 2026.
