Review a vendored update by checking what changed in the manifest and the vendor listing first, then diffing the vendored files against the upstream release for that version, and finally scanning the result. Vendoring turns an invisible dependency change into a visible diff, which is its main security advantage.
What vendoring means for intake
When dependencies are vendored, a copy of their source sits inside your repository. The Go modules reference explains that with a vendor directory present and a go version of 1.14 or higher in go.mod, the go command acts as if the vendor mode were selected by default, and in that mode it will not use the network or the module cache. Cargo offers a similar path: its source replacement feature can replace crates.io with a vendored directory.
For intake, the consequence is useful. A version change is a pull request with the actual code changes in it. The danger is the opposite one: big diffs get approved without anyone reading them.
A review in four passes
- Read the summary files. In Go, that is go.mod and the vendor listing file; in Cargo, the manifest and lockfile. Which packages were added, removed or changed, and by how much?
- Check the delta against the upstream release. Confirm that the vendored files for a version match the files published for that version. A mismatch means someone edited vendored code, intentionally or not.
- Scan for risky additions. Look for new network calls, process execution, file system writes outside expected paths, and build scripts.
- Run the usual policy checks. License, advisories, source and publisher.
Make the diff smaller
| Technique | Effect |
|---|---|
| One dependency update per pull request | Reviewers see one story at a time |
| Separate the vendor commit from the code that uses it | Cleaner history |
| Generated file markers | Tools can skip files you never edit by hand |
| An automated comparison job | Compares vendored files with upstream and reports differences |
A comparison job
The most valuable automation is a job that re-creates the vendor directory from the manifest in a clean environment, and fails the pull request if the result differs from what was committed. This catches hand edits and partial updates. Run it through your mirror so the sources are the ones you approved.
Handling edited vendored code
Sometimes a team patches a vendored package. That is a fork in practice. Record it: why, who owns it, what the upstream issue is, and a date to revisit. Edited vendored code will not receive upstream fixes automatically, so it needs an owner who watches advisories.
Common mistakes
- Treating a vendored directory as trusted because it is in your repository. Code in your repository is yours to review.
- Skipping scanning for vendored code because there is no lockfile to read. Scanners that read the vendor listing or source can still inventory it.
- Letting generated changes bypass code review rules.
Where Safeguard fits
Safeguard's SBOM and dependency scanning can inventory packages from supported manifests and vendored layouts, and gates can apply policy on the pull request. Try the free scan on a repository.
Quick check
Is vendoring safer than using a mirror?
They solve different problems. Vendoring gives visibility and offline builds, while a mirror gives central control. Many teams use both.
Do vendored dependencies still need scanning?
Yes. Known vulnerabilities in vendored code are just as exploitable.
Sources
Last reviewed: 19 October 2026.
