When a scanner cannot work out a component's name or version, it usually cannot compare it with advisory data, so the component produces no findings. That looks like safety but is really an unknown. Good tools list unidentified items separately; weaker ones drop them silently. Ask which behaviour yours has.
Why identification fails
Matching depends on two facts: which package this is, and which version. Either can be missing.
- A library was copied into a source tree (vendored) with no metadata.
- A jar or binary was repackaged, so its original coordinates are gone.
- A package came from a private registry with a name no advisory database knows.
- A version string is unusual, such as a build hash or a date.
- A compiled file statically links code, leaving only traces.
Advisory records identify affected software by ecosystem, name and version information. The OSV schema, for instance, expects a package with an ecosystem and name, and can include a purl, plus version ranges. No identity, no lookup.
Three possible outcomes
| Behaviour | What you see | Risk |
|---|---|---|
| Silent skip | Nothing in the report | You assume it was checked |
| Reported as unidentified | A separate list or count | You can investigate |
| Educated guess | A finding with a confidence note | Possible false positives, but visible |
The second and third are far better than the first. A report that includes a count of components with no usable identifier tells you how much of the project the scan could actually judge.
How to surface the unknowns
- Generate an inventory and count components that lack a version or a purl.
- List directories that hold code but no manifest, such as vendor folders.
- Compare the inventory with the contents of the built artifact. Files present in the artifact but absent from the inventory are candidates.
- For each unknown, decide: identify it, replace it with a managed dependency, or record it as an accepted gap with an owner.
Step four is where the work pays off. Replacing a vendored copy with a proper dependency gives you matching, updates and a clear fix path.
What to put in your report
Add one line to every scan summary: how many components were identified and how many were not. A scan with 400 identified components and 30 unknown ones is honest. A scan that reports only the 400 is not wrong, but it hides the 30.
What about advisory gaps?
A different failure looks similar. The component is identified, but no advisory exists yet, or the advisory has no version data. That is a data gap, not an inventory gap. Tracking the two separately helps, because the fixes differ: one needs better inventory, the other needs better or fresher vulnerability data.
Where Safeguard fits
Safeguard's SBOM and dependency scanning builds an inventory and its asset discovery helps locate projects that were missing from it. A free scan shows what was identified in a project of yours, so you can compare it with what you expect.
Quick check
Does an unidentified component mean it is vulnerable?
No. It means the scanner cannot tell. It could be safe or vulnerable, which is why it should be investigated rather than ignored.
What is the quickest way to find vendored code?
Look for directories that contain source or binaries but no manifest or lockfile, then compare the built artifact with the inventory.
Sources
Last reviewed: 19 October 2026.
