Check the ecosystem first. Package registries are separate, so a name in the news may refer to an npm package, a PyPI project or another registry's entry, and a different package with the same name can exist elsewhere. Confirm which registry, which publisher and which versions before you search your systems or act.
Why the same name can mean different things
Each ecosystem runs its own registry with its own names. The GitHub Advisory Database documentation lists its supported ecosystems by registry: Composer, Erlang, Go, GitHub Actions, Maven, npm, NuGet, pip, Pub, RubyGems, Rust and Swift. Each has its own namespace.
A name that is unique within one registry is not guaranteed to be unique across all of them. Two unrelated projects can share a name, one on npm and one on PyPI, and a headline that gives only the name does not say which one it means.
This matters in two directions. You may search for the name, find your own unrelated package of that name and panic. Or you may find nothing in your npm lockfile and relax, when the story was about the Python package you run.
What to confirm
| Check | Why |
|---|---|
| Ecosystem and registry | Names are only unique inside one registry |
| Exact package name, including any scope or namespace | Scoped and unscoped names are different packages |
| Publisher or maintainer | Tells you which project the story concerns |
| Repository link | Lets you match the story to the code you use |
| Affected versions | A name match with a safe version is not an exposure |
| Where you got your copy | Your lockfile may point at a different source |
Do not skip to the version. A version number means nothing until you know which package it belongs to.
Step by step
- Read the primary source for the ecosystem. If the source does not state it, look for the registry URL or the install command in the notice. An install command such as
npm installorpip installnames the ecosystem. - Search the advisory database with an ecosystem filter. The documentation lists the
ecosystem:qualifier, for exampleecosystem:npm, andaffects:for a library name. Run the search for each ecosystem you use and compare the results. - Open each registry page. Check the publisher, the repository link and the version history. The PyPI documentation notes that metadata comes from values provided at upload time, so match the repository link against other evidence as well.
- Search your own systems with the right file types. For npm, search
package.jsonand lockfiles. For Python, search requirements files and lock files. Search each ecosystem separately. - Write the ecosystem into the ticket title. "npm: some-package 3.0.4" is clearer than "some-package".
A worked example
A headline says "a package called quickparse was found to be malicious". You run a Node service and a Python data job.
You search your Node lockfiles first and find a package named quickparse, version 1.4.0, as a transitive dependency. Alarming. Then you read the notice properly: it includes the line pip install quickparse, so the story concerns the Python package.
You check the registry pages. The npm package named quickparse has a different publisher and a repository about string parsing in JavaScript. The PyPI project is a different publisher and a data tool. They are unrelated.
You search your Python requirements files and find no mention. You record: "Story concerns the PyPI project. Our npm package of the same name is a different project. Python job does not use it. Not affected." You attach the notice, the two registry pages and your search results.
Without the ecosystem step you would have spent an hour investigating an unrelated package and might have rotated credentials for nothing.
The same trap in other forms
- Scoped names. In npm, a name with a scope, such as
@team/utils, is distinct from an unscopedutils. Read the scope. - Similar names. Typosquatting relies on names that look alike. A package whose name differs by one character is a different package. Compare character by character.
- Forks and mirrors. A fork on a code hosting site shares a name with the original, yet the story may concern only one of them.
- Internal packages. Your own private package may share a name with a public one. A story about the public package does not touch your internal one, though it is worth checking how your build resolves the name. See the post on dependency confusion versus typosquatting.
Teach the habit
Add "ecosystem and publisher" to your news triage ticket template as required fields. A required field is cheap, and it prevents the most common false alarm and the most common false comfort.
When you tell colleagues about a story, say the ecosystem first: "npm package X" or "PyPI project Y". It sets the right frame for everyone.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how every component and version gets an entry, and whether each entry shows which ecosystem it belongs to.
Safeguard's SBOM and dependency scanning keeps packages organized per project, which makes it easier to search one ecosystem at a time.
Quick check
Can an npm package and a PyPI project share a name?
Yes. Registries are separate, so names are unique only within each one. Always confirm the ecosystem before you act.
How can I tell which ecosystem a headline means?
Look for an install command, a registry URL or a repository link in the primary source, and check the publisher on each registry page.
Does a name match in my lockfile mean I am affected?
No. You also need the right ecosystem, publisher and a version in the affected range.
Sources
- About the GitHub Advisory Database
- Browsing security advisories in the GitHub Advisory Database
- PyPI JSON API documentation
Last reviewed: 19 October 2026.
