To confirm you have the official package, follow links in both directions: from the project's own documentation to the registry page, and from the registry page back to the repository. If they point at each other and the name matches exactly, it is likely authentic. A similarly named package that is more popular is a warning sign.
Why this is the first check
All the later checks, such as maintainer activity and vulnerability history, are meaningless if you are looking at the wrong package. The OpenSSF evaluation guide begins with this: verify authenticity, meaning confirm you have the authentic project and not an impostor or unofficial fork. Under adoption it adds name verification: check whether a similarly named package is more popular, which could signal typosquatting.
A two way link check
- Start from the project's official site or the repository you trust, not from a search result or an AI suggestion.
- Find the install command in the official documentation. Copy the package name exactly from there.
- Open that name on the registry. Does the registry page link to the same repository?
- Open the repository. Does its manifest and README mention the same package name and link back to the site?
- Compare the repository owner with the organization you expected.
When all links agree, you have good evidence. When one is missing, ask why.
Signs of an impostor
| Sign | Why it matters |
|---|---|
| Name differs by a character, hyphen or plural | Typical typosquatting pattern |
| Registry page links to a repository that does not mention the package | Linkage was claimed, not earned |
| Brand new package copying a known README | Copy of the real project |
| Much lower usage than a near identical name | The popular one is probably the real one |
| Owner differs from the project's organization | Could be a fork or an impostor |
Forks are not always bad
An unofficial fork can be legitimate, for example when the original project stalled. The risk is not that it is a fork but that you did not know. Treat a fork as its own project: check who maintains it, why it exists and how it is kept current.
Habits that prevent mistakes
- Never copy an install command from a chat answer without checking the name on the registry. AI assistants can suggest packages that do not exist or look like real ones.
- Use a lockfile so the exact package you reviewed is the one that installs.
- Consider an approved package list for common needs, so engineers pick from a vetted set.
- Review new names in pull requests. A single unfamiliar package in a diff is easy to miss.
Try it yourself
Open the demo and read the package names in the inventory. Would you spot a near miss spelling?
Click through it at your own pace, or open it full screen.
Quick check
Is a fork always an impostor?
No. Forks can be legitimate, but treat them as separate projects and check who maintains them and why they exist.
Why not trust a search result?
Search results can rank copycat packages. Start from the project's official documentation and verify links both ways.
Safeguard's SBOM and dependency scanning lists exactly which package names are in your code, and its policy gates can flag new additions in pull requests. Try the free scan.
Sources
Last reviewed: 19 October 2026.
