Find vendored or copied libraries by looking for third party source or binaries inside your repository, identify the upstream project and version, check it against advisories, then replace it with a managed dependency. If you must keep the copy, record its origin and patch status and treat it as your own code.
Why they are a blind spot
Dependency scanners usually read manifests and lockfiles. A library copied into a source folder, or a jar checked into the repository, has no manifest entry. It does not show up in an inventory, so its vulnerabilities go unseen. Legacy apps built before modern package managers are full of these.
Teams also modify copies. A patched copy no longer matches any published version, which makes identification harder.
Where to look
- Directories named vendor, lib, third_party, external or contrib
- Binary files such as jar, dll, so and wasm checked into version control
- Minified JavaScript files with a copyright header
- Large source files with a license header from another project
- Build scripts that download archives from a URL
A step by step method
- Search for candidates using the locations above, plus license headers.
- Identify the upstream project. Read headers, version strings in the code and file hashes. Compare hashes to published release files.
- Determine the version, or the closest one. If the code was modified, diff it against the nearest release.
- Check advisories for that version range.
- Decide: replace, update the copy, or keep and own it.
- Record the result in your inventory so future scans include it.
| Finding | Decision |
|---|---|
| Unmodified copy of a published release | Replace with a managed dependency |
| Modified copy, patches are small | Upstream the patches or re-apply them to a managed version |
| Modified heavily, no upstream equivalent | Keep, treat as first party code, review it for the known flaw classes |
| Binary with unknown origin | Treat as high risk, replace or remove |
Replacing with a managed dependency
Add the library to your build file at the fixed version, remove the copied files, build and run tests. Watch for differences in packaging, since the copy may have been trimmed to leave out parts you were not using.
If you must keep the copy
Write a small file next to it stating the upstream name, version, license and the date it was last compared. Add a calendar reminder to review. Some teams add a check in CI that the file hashes still match what was recorded, so unexpected edits are caught.
How this fits modernization
When a feature is extracted into a new service, do not copy the vendored library along with the code. Use the managed version in the new service. That also gives you a natural moment to retire the copy from the monolith. See legacy software supply chain risks and the post on whether to vendor dependencies into your repo.
Safeguard's SBOM and dependency scanning is built around inventories, and the free scan at gold.safeguard.sh/scan lets you check what it finds in a repository.
Quick check
Can a scanner find a copy that was edited?
Sometimes by similarity, but you should not rely on it. Manual identification and a record of origin are safer.
Is vendoring always bad?
No. Vendoring on purpose, with a record and an update routine, is a legitimate choice. Unrecorded copies are the problem.
Last reviewed: 19 October 2026.
