Code copied into your repository does not appear in your lockfile, so dependency scanners often miss it. To find it, search for vendor folders and license headers, record each copy's origin and version in a manifest, and put the manifest in your SBOM so it is checked like any other dependency.
Why copied code is invisible
Most dependency scanning starts with manifests and lockfiles. A library that was pasted in, vendored into a third_party folder, or bundled as a minified file has no entry there. The advisory exists, but nothing connects it to your code.
Teams copy code for good reasons: patching a library locally, avoiding a network fetch at build time, or working around a dead package. The problem is that the origin and version are easily forgotten.
Step 1: Find it
Look in these places:
- Folders named vendor, third_party, external, or lib that hold full source trees.
- Files with license headers naming another project.
- Minified or bundled files in static asset directories.
- Copied scripts in build tooling and container images, such as a downloaded installer.
- Git submodules, which point at an external repository.
Search code for well known project names and license text. Hash matching tools can also compare your files against known package contents.
Step 2: Record the origin
For each copy, write down the upstream project, the exact version or commit, the date copied, who owns it, and whether it has local changes. A short file in the same folder works. This is the minimum you need to answer "are we affected?" when an advisory appears.
Step 3: Make it visible to scanners
Add the copies to your SBOM as components with their upstream names and versions. A copied component with no entry is a gap in the inventory. Once it appears there, advisory matching can work for it.
Step 4: Decide how it gets updated
| Situation | Approach |
|---|---|
| Unmodified copy | Replace it with a normal dependency if possible |
| Modified copy | Keep a patch file against upstream, so updates can be re applied |
| Abandoned upstream | Own it explicitly, and schedule review |
| Bundled binary | Rebuild from source, or fetch a pinned release at build time |
Local modifications are the biggest risk. Without a patch record, nobody dares to update, and the copy ages in place.
What about AI generated snippets?
Pasted code from forums or chat tools has no provenance at all. See the hidden risk of copy pasted code snippets. Treat larger pasted blocks like vendored code: record where they came from.
Try it yourself
Open the demo and look at how a dependency inventory lists components with versions. Notice what would be missing if a vendored copy were not in it.
Click through it at your own pace, or open it full screen.
Quick check
Does a lockfile scan catch vendored code?
Usually not, since the code has no lockfile entry. You need to add it to your inventory yourself.
Is vendoring always bad?
No. It can be reasonable, but only with a recorded origin and an update plan.
Safeguard's SBOM and dependency scanning can generate an inventory of the components in a repository, and the free scan at gold.safeguard.sh/scan is a quick way to see what turns up.
Last reviewed: 19 October 2026.
