If a component keeps its name but its package URL namespace or supplier differs between SBOMs, you may be looking at a rename, a fork, a moved project or a lookalike package. Confirm it is intended, who maintains it now, and whether the identifier change breaks your vulnerability matching.
Why this change is easy to miss
A diff that matches only by name can treat the two entries as the same thing. A diff that matches by full package URL will show one component removed and another added. The second view is more honest and also noisier, so teams sometimes filter it out. That is where it hides.
A package URL has a type, an optional namespace, a name and a version, plus optional qualifiers. The namespace has a meaning that depends on the type, such as a Maven group or a GitHub owner. Changing it changes who the package is claimed to come from.
Plausible explanations
| Explanation | Evidence to look for |
|---|---|
| Project moved to a new organisation | Announcement in the repository, redirects, registry notes |
| Maintainers published a fork after a dispute | Public discussion, differing release history |
| Library was renamed upstream | Changelog and migration notes |
| Your own team switched to a vendored or internal copy | A commit in your repository |
| Lookalike or typosquatted package | Different publisher, recent creation, small history |
| Generator now reports a different field | Same artifact, different metadata convention |
Steps
- Take the old and new package URLs and put them side by side.
- Check the registry pages for both: publisher, creation date, release history and download counts.
- Look in your repository for the commit that changed the dependency.
- Ask the author of that commit why.
- If nobody can explain it, treat it as suspicious and hold the release.
Typosquatting and dependency confusion rely on small identifier differences, so a changed namespace on a familiar name is exactly the pattern to examine.
Effects on tooling
Vulnerability matching depends on identifiers. If advisories are filed against the old namespace, the new entry may match nothing and look clean. A change of identity can silently drop known vulnerabilities from your results. After any accepted rename, test that your scanner still maps the component to advisories, and keep a note of the old identifier for history.
Make the check automatic
Add a rule that flags a component whose name matches one in the baseline but whose namespace, supplier or type differs. Send those to a person. The count is usually tiny, so the cost of reviewing is low and the value is high.
Safeguard scans dependencies and SBOMs, and its policies can act on component identity changes. Check a project quickly with the free scan.
Quick check
Is a changed namespace always a problem?
No. Moves and renames are common. The problem is an unexplained change, so ask for the reason.
Could a rename hide vulnerabilities?
Yes, if advisories are filed under the old identifier. Test matching after accepting the change.
Sources
Last reviewed: 19 October 2026.
