Before adding a dependency, spend ten minutes on seven checks: confirm the exact name, look at who publishes it and how it is released, read its recent history, check what runs at install time, count what it pulls in, consider whether you need it at all, and pin it. Most bad choices fail one of these quickly.
Check the name and the publisher
Name. Typed names go wrong. Copy the name from the project's own documentation, not from a search result or an AI answer. Check ecosystem rules: in Python, separators and case are normalized, so a differently spelled name may be the same project, while a one letter difference is a different one. In npm, check the scope spelling exactly. Chat assistants sometimes suggest package names that do not exist, and an attacker can register such a name, so confirm that the package exists and is the one you meant.
Publisher. Look at the maintainers, the linked repository and whether the registry page points to the same repository as the project site. Check that the repository link goes to a real project and that the code in the repository matches what the package claims to do. A package with no repository link deserves caution.
Read the history and the install behavior
History. Open the release list and the changelog.
- Is there a steady cadence, or a long gap followed by a sudden release?
- Did the maintainer list change recently?
- Do open issues mention security reports or suspicious behavior?
- Is the project archived or marked as unmaintained?
A quiet project is not bad by itself. A quiet project that suddenly releases a new major version with new maintainers needs a closer read.
Install time. Check for install or build scripts, native extensions and binary downloads. Anything that executes during installation runs with your permissions. If you see network calls in an install script, find out why. Where your tooling allows it, install with scripts disabled first and see whether the package works.
Weigh the cost
Reach. List the transitive dependencies it adds. A small utility that brings in forty packages multiplies your exposure. Look at whether those are well known or obscure. Weigh the benefit against that cost.
Need. Could the standard library do the job? Could you write the ten lines yourself? For tiny helpers, owning the code is often safer than adding another publisher to your trust list. For complex or security sensitive tasks, such as cryptography or parsing untrusted formats, use a well reviewed library rather than writing your own.
Pin and record
Add it with an exact version, commit the lockfile with hashes, and note why it was added in the pull request. Let a scanner check the new set before merge. Delay adopting brand new releases of the package if your policy allows, so there is time for problems to be reported.
Make it a habit
Put the checklist in your pull request template for changes that touch manifests, so the reviewer sees the answers. Safeguard scans dependencies and can gate pull requests that add flagged packages, which handles part of this automatically; the rest takes a person.
Quick check
Is a package with many downloads automatically safe?
No. Download counts can be inflated and popular packages have been compromised. Use the checklist rather than popularity.
Should I install an AI suggested package without checking?
No. Confirm that the package exists, that it is the one you intended and that its publisher and history look sound before adding it.
Last reviewed: 19 October 2026.
