Vendoring makes builds more repeatable and removes the network from the build, which helps against a registry outage or a replaced download. It does not make the code safer. You now own a copy of other people's code, including its vulnerabilities, and you must review and update it on purpose.
What vendoring is
Go and Cargo both have a built-in command. The Cargo book says cargo vendor copies all crates.io and git dependencies into a directory, and that Cargo treats vendored sources as read-only. In Go, go mod vendor builds a vendor directory with the packages the main module needs. The Go reference notes that at Go 1.14 or higher, automatic vendoring can apply when vendor/modules.txt is present and consistent with go.mod.
What it improves
| Benefit | Why |
|---|---|
| Repeatable builds | The exact source is in your repository |
| No network at build time | An outage or removed package cannot break the build |
| Reviewable changes | A dependency update appears as a diff in a pull request |
| Tamper evidence | A changed vendored file shows up in version control |
What it does not fix
- Known vulnerabilities. A vendored copy of a vulnerable library is still vulnerable, and scanners must read the vendor folder or the manifest.
- Malicious code you copied in. If the version was bad when you vendored it, you vendored the problem.
- Update lag. Nobody gets security fixes automatically unless you refresh the vendor directory.
- Review fatigue. A diff of thousands of lines is easy to wave through.
How to vendor responsibly
- Vendor from a pinned, verified source: lockfile and checksums first.
- Commit the vendor directory and the lock data together so they cannot drift.
- Make CI verify that the vendor directory matches the manifest, and fail if it does not.
- Review the diff for new files, new install scripts, and unexpected network calls, not only version bumps.
- Scan the vendored code for known vulnerabilities and licenses on every pull request.
- Schedule updates. Treat the vendor folder like any dependency that needs patching.
Vendoring or a private mirror
A private mirror keeps the registry model but holds a copy of what you use. Vendoring puts the copy in source control. Mirrors scale across many projects, vendoring gives the strongest per repository isolation. Many teams use both. Compare in internal registry, mirror or proxy.
Safeguard's SBOM and dependency scanning reads the dependencies in your repository, so vendored code still shows up in the inventory.
Try it yourself
Click through it at your own pace, or open it full screen. See how the inventory lists direct and transitive packages, which is what a vendor folder hides in plain sight.
Quick check
Does vendoring remove the need to scan?
No. Vendored code carries the same vulnerabilities as the original, so it still needs scanning and updates.
Are vendored crates editable?
Cargo treats vendored sources as read-only. To change one, use a patch entry or a path dependency to a local copy.
Sources
Last reviewed: 19 October 2026.
