Yes, if a tool matches on name alone. The same name can exist in two ecosystems as unrelated software, so a reliable match needs the ecosystem as well. When a finding names a package you do not recognise, check the ecosystem and the full Package URL before you doubt your dependency list.
Why name alone fails
Package registries are separate namespaces. Nothing stops npm and PyPI from each hosting a package called the same thing. The OSV schema says this directly: both ecosystem and name are required, because the ecosystem determines how the name is interpreted, and it gives the example that zlib in npm and PyPI refers to different packages.
That is why serious vulnerability data always pairs the two. A record that said only "zlib" would match software that has no relation to the flaw.
How the ecosystem field is scoped
The ecosystem value can be narrower than a registry. The schema notes that some values accept a suffix to scope a release, for example Debian:7 or Alpine:v3.16. A wildcard * means all packages in the ecosystem, which is useful for end-of-life ecosystems. So "the same name" can also differ across releases of the same distribution.
Package URL as the tie-breaker
A Package URL (PURL) is a standard syntax for identifying packages across ecosystems:
scheme:type/namespace/name@version?qualifiers#subpath
The scheme is the constant pkg. The type is the package protocol, such as maven, npm, nuget, gem or pypi. The namespace is optional and type-specific, such as a Maven group ID or a Docker image owner. The OSV schema also lets a record carry a purl for the package, without the version part.
Two packages with the same name and different types are different PURLs:
pkg:npm/example
pkg:pypi/example
A scan report that lists PURLs lets you check a match in seconds. One that lists only names makes you guess.
What to check when a finding looks wrong
- Find the ecosystem and name the scanner reports. If it only shows a name, open the details or the raw output.
- Find where the package came from in your build. Look at the manifest or lockfile that mentions it.
- Confirm the ecosystem of that manifest. A package.json is npm, a requirements file is PyPI.
- Compare with the advisory. Open the record and read its affected package entry. Does the ecosystem match?
- If the ecosystems differ, you have a false match. Report it to the tool maker with the PURL and the advisory ID, and suppress it with a note while you wait.
A related risk worth knowing
Name confusion has a security side too. Attackers sometimes publish packages whose names resemble or mimic internal ones. GitHub's advisory documentation describes malware advisories where a public package reuses the name of a private or third-party dependency, and notes that properly scoped dependencies are less exposed. So when a name looks odd in a scan, do not assume a scanner error. Check the registry listing and who published it.
Keep your own inventory by PURL
If you track components in a spreadsheet or an SBOM, store the PURL, not just the name. It makes matching against advisories, VEX statements and licence data less error-prone, and it keeps conversations between teams precise.
Safeguard's SBOM and dependency scanning record components with their ecosystem, so findings are tied to the right package. A free scan is at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Notice that each component is listed with where it came from.
Quick check
What is a PURL?
A Package URL is a standard string that identifies a package by type, optional namespace, name and version, such as pkg:npm/name@1.2.3.
Is an unexpected package name always a scanner mistake?
No. It may be a false match, or it may be a package you did not mean to depend on. Check the manifest and the registry listing.
Sources
- OpenSSF, OSV schema
- Package-URL, PURL specification README
- GitHub Docs, About the GitHub Advisory database
Last reviewed: 19 October 2026.
