Review Package Registry Trust
Check a new package's namespace, publisher rights, release history, and exact artifact before adding it to a build.
A dependency name in a manifest is not enough to establish identity. Similar names, ownership changes, and registry namespaces can make a package look familiar while pointing to a different publisher. Review the exact package coordinate before adding it to a production build.
The OpenSSF Scorecard checks describe repository practices such as maintained status and dependency handling. OWASP's dependency guidance calls for deliberate selection and monitoring. Neither source can tell you that a package is trustworthy from a single score. Use them as inputs to a specific adoption decision.
Adoption record
| Field | What to verify |
|---|---|
| Ecosystem | npm, PyPI, Maven, crates.io, or another registry |
| Namespace | Exact owner and package spelling |
| Publisher | Account or organization authorized to release |
| Repository | Link from the registry and matching project identity |
| Version | Exact archive and digest to install |
| Release history | Recent changes, yanks, ownership transfer |
| Use | Why the application needs this dependency |
| Exit path | Who can update or replace it |
Compare the name character by character with the upstream project's official install instructions. Inspect the registry's publisher and release metadata. Do not assume a README link is trustworthy because a package can edit its own README. Where the registry provides provenance, verify it against the consumed artifact rather than treating a badge as proof.
Controlled adoption check
Install the candidate in an isolated owned build with no production credentials. Pin the resolved version and inspect the lockfile change. Review lifecycle scripts and permissions that execute during installation. Run a small functional test that covers the intended feature. If the package requests unrelated network or filesystem access, pause and inspect the reason before promoting it.
Worked adoption decision: fictional package
For a proposed @example/parser@1.2.3, record the approved registry host, exact lockfile resolution and integrity value, registry publisher, and archive digest. Suppose the publisher changed since the prior release while the repository link stayed the same. Hold this version for a privileged upload path until the owner confirms the transfer and the archive-to-source evidence is checked. A clean isolated install is a compatibility signal, not proof of publisher continuity. Record the final accept or reject decision with the reviewer and date.
Know which dependency risks need a fix
Check affected versions, the build and deployment evidence. Use the update checklist, or discuss the dependency risks in your application review.