Treat unmatched triage records as a signal, not clutter. Sort them into four causes: the component is gone, the advisory ID changed, the two tools disagree on whether it is vulnerable, or the new scanner cannot see that file type. Only the last two are risks to chase before you retire the old tool.
Why orphans appear
After you import decisions and run the first scan, you will find old records with no partner. This is normal. Two scanners use different advisory sources, parse manifests differently, and name the same package in different ways. A one to one match is rare, so plan for a remainder.
The four causes
1. The component no longer exists. The dependency was removed, upgraded or the repository was archived. The decision is obsolete. Archive it.
2. The identifier changed. The same vulnerability has several IDs. The OSV schema defines an aliases field for exactly this, listing IDs of the same vulnerability in other databases, and says aliases are symmetric and transitive. Rematch using aliases and the package identifier before you conclude anything is missing.
3. The tools disagree. The old scanner flagged the package, and the new one does not. Maybe the new tool's advisory data places the affected range differently, or it decided the version is fixed. This needs a human to read both advisories. It may mean the old tool had a false positive, or that the new tool has a gap.
4. The new tool cannot see it. The old scanner read a file type, such as a vendored archive or a lockfile format, that the new one skips. This is a coverage gap, and the most important category.
Steps to sort them
- Export the unmatched records with package, version, advisory ID and repository.
- Check whether the repository and component still exist in the default branch. Drop the obsolete ones.
- Retry the match using advisory aliases and normalized package names.
- For the rest, read the advisory in two sources and note which tool seems right.
- For any record where the old tool saw something the new one could not parse, open a coverage ticket with the vendor.
| Cause | Action | Risk if ignored |
|---|---|---|
| Component removed | Archive | None |
| ID changed | Rematch with aliases | Duplicate triage |
| Tools disagree | Manual advisory review | Missed or false finding |
| Coverage gap | Ticket and workaround | Blind spot |
How many orphans is too many?
There is no universal threshold. Track the percentage of triaged records that remain unmatched after the alias rematch. If it is a few percent and mostly obsolete components, move on. If it is a large share, or concentrated in one repository or ecosystem, you have found a coverage issue, and that decides whether the old tool can retire.
Keep the old tool until orphans are resolved
Do not cancel anything until the third and fourth groups are empty or explained. Put it in your exit criteria. Orphans are the cheapest early warning you will get about a scanner that looks complete on the dashboard but is not.
Try it yourself
Open the demo and look at how components are inventoried with their versions and sources. Notice what identity details a scanner has to match against.
Click through it at your own pace, or open it full screen.
Quick check
Should orphans be deleted?
Archive them as read only records. Deleting removes your only evidence of why something was once judged safe.
What identifiers help rematching?
Package URL style identifiers, normalized names and the advisory aliases listed in OSV records.
Sources
Last reviewed: 19 October 2026.
