Copy a known old release of a library into a throwaway repository as a plain file, with no manifest entry, and scan it. If your scanner reports it, it can fingerprint vendored code. If not, copied files are a blind spot you need to cover another way.
Why vendored code is the hard case
Manifest scanning works from declarations. A file dropped into a vendor or static folder has no declaration. Detecting it needs file hashing, header comment matching or binary analysis, which not every scanner does. Related background is in copied code and your SBOM.
Choose the canary
jQuery is a good candidate because its own release notes document a security fix. The jQuery 3.5.0 release post, dated 10 April 2020, describes an issue in jQuery.htmlPrefilter that could introduce a cross site scripting vulnerability, and says the HTML parser in jQuery 3.4.1 and earlier had edge cases with unintended consequences. So a copy of a pre 3.5.0 file is a sensible canary.
The 15 minute test
- Create a private repository with a single folder named
static. - Download an older jQuery release file from the official jQuery site or its archive, for example version 3.4.1, and save it into
static. - Do not add a package.json. The point is that nothing declares it.
- Run your scanner exactly as your pipeline does.
- Check the findings for jQuery and its advisory.
- Now rename the file to
lib.jsand scan again. Fingerprinting by filename fails here, while hash or content matching still works. - Minify or concatenate it into a bundle if your build does that, and scan once more.
Reading the three runs
| Run | Detected | What it tells you |
|---|---|---|
| Original filename | Yes or no | Filename matching at least |
| Renamed file | Yes or no | Content or hash matching |
| Inside a bundle | Yes or no | Depth of analysis |
A tool that passes only the first run relies on filenames. A tool that passes all three can see vendored code in realistic conditions.
If it fails
- Convert vendored files into declared dependencies wherever possible.
- For the rest, keep a third party inventory with name, version and source, and feed it into your SBOM.
- Add a check in review that new files under vendor folders come with an inventory entry.
- Note the limitation in your coverage statement.
See also exceptions for vendored or forked code you do not own.
Safeguard offers SBOM and dependency scanning and a free scan at gold.safeguard.sh/scan. Whatever you use, run the three file test.
Quick check
Why not just trust the scanner vendor's coverage claim?
Claims describe typical cases. A test on your own file layout shows what happens in your repositories.
Does a missed vendored file mean the library is vulnerable?
Not necessarily. It means the scanner cannot tell, so you must determine the version yourself.
Sources
Last reviewed: 19 October 2026.
