Before installing a new dependency, confirm that the repository linked from the registry page is the project you meant, that it is not a fork or lookalike, and that any build attestation points to the same repository. Mismatches are cheap to spot and a common first sign of a wrong package.
Why identity comes first
The OpenSSF Concise Guide starts its evaluation with authenticity. It asks you to verify the software is the authentic version from the authorized source, not a personal fork or an attacker-controlled fork, and notes these techniques counter typosquatting, where an attacker creates an almost correct name. Its suggested steps are short: check the name and the project website for the link, verify the fork relation on the hosting site, check whether the project is affiliated with a foundation, and check its creation time and popularity.
A five minute identity check
- Start from the project's own website or documentation, not from a search result, and follow its link to the registry listing. Then compare the name letter by letter.
- On the registry page, open the repository link. Confirm the owner and repository name match what the project's site says.
- On the hosting site, check whether the repository is a fork. GitHub shows the fork relation, and its network graph and forks list help you understand how repositories connect.
- Compare creation dates. A very new repository or package with a familiar name is a flag.
- If the version has a build attestation, read its source repository field. npm provenance publicly links a package to its source and build instructions, and the deps.dev API exposes the source repository and commit for npm provenance data. They should match the repository you identified.
What a mismatch can mean
| Observation | Possible meaning | Next step |
|---|---|---|
| Link points to a different owner | Lookalike or moved project | Check the project's own site |
| Link missing | Small or careless project | Treat identity as unconfirmed |
| Repository is a fork | Maintained fork or copy | Find the upstream and compare |
| Attestation names a different repository | Repackaged or republished | Ask before installing |
Most of these have innocent explanations. Projects move organizations, and maintained forks are common. The check is about replacing guesses with a short confirmation.
What the check does not prove
A matching link does not prove the contents are safe. A repository link in package metadata is typed in by the publisher. It is a claim. An attestation is stronger, because it is generated in the build environment, but it still proves where something was built, not that the source is benign. Pair this check with maintenance and review signals.
Make it a habit
Add the identity check to your dependency approval step, and keep a one line note: repository URL, owner, creation date, fork status and attestation match. When the same package is updated later, repeat the comparison quickly, because a changed link between versions is worth noticing.
Try it yourself
Click through it at your own pace, or open it full screen. See how a gate can hold a pull request that adds a dependency until a check is answered.
Where Safeguard fits
Safeguard provides SBOM and dependency scanning and policies and gates that can hold changes for review. A free scan is at gold.safeguard.sh/scan.
Quick check
Can I trust the repository link on the registry page?
Treat it as a claim made by the publisher. Confirm it from the project's own site and, where available, from a build attestation.
Is a fork always a problem?
No. Many forks are maintained legitimately. Find the upstream and understand why the fork exists.
Sources
- OpenSSF Concise Guide for Evaluating Open Source Software
- GitHub Docs: Understanding connections between repositories
- npm Docs: Generating provenance statements
- deps.dev API v3 documentation
Last reviewed: 19 October 2026.
