Before adding a dependency, ask whether you need it, who publishes it, what runs at install time, how old and active it is, where it comes from and how you would remove it. Ten questions take about five minutes and catch most of the avoidable risks.
The ten questions
- Do I need it? A package you do not add cannot be compromised. Check whether the standard library or existing code covers the need.
- Is the name exactly right? Confirm spelling and publisher against the project's own documentation, since lookalike names are a common trick.
- Who publishes it? Look for an organization or a known maintainer, and how many people can release.
- What runs at install time? Check the manifest for install scripts. The npm ignore-scripts setting stops scripts in package.json files from running, and pnpm v10 disables automatic postinstall scripts in dependencies, so you may need to allow a build explicitly.
- How new is this version? Pnpm's documentation suggests delaying adoption of new versions, with a default of one day for its minimum release age setting.
- What does it pull in? A small package can add a long chain of indirect dependencies. GitHub's dependency review shows added dependencies including indirect ones from lock files.
- Are there known vulnerabilities? Dependency review reports whether added or updated dependencies contain known vulnerabilities.
- Where does it download from? Confirm the source your build will use, and that private names cannot be claimed publicly.
- Does the published package match its repository? Where provenance exists, check it points to the expected repository.
- How will I remove or replace it? Note the planned exit before you depend on it.
Scoring it
You do not need a formal score. Mark each answer green, amber or red. Two reds, or any red on questions two, four or eight, means stop and look again.
Where to write it down
Add a short section to the pull request that adds the dependency. A template with the ten questions as checkboxes works well. Reviewers then see the reasoning, and future maintainers learn why the package is there.
Common traps
- Adding a package to save ten lines of code.
- Copying an install command from a tutorial without checking the name.
- Accepting the first search result.
- Approving a pull request that adds a dependency along with unrelated changes.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how one package expands into a tree of transitive dependencies.
Where Safeguard fits
Safeguard's dependency scanning and reachability analysis show what a new package brings and whether vulnerable code is actually reachable, and policies can gate the pull request. A free scan lets you try it on a project.
Quick check
Is five minutes realistic?
For a small, well known package, yes. For one that runs install scripts or has many transitive dependencies, take longer.
Do these questions apply to dev dependencies?
Yes. Build and test tools run on machines that hold credentials, so they are entry points too.
Sources
- npm Docs: npm install, ignore-scripts
- pnpm: Mitigating supply chain attacks
- GitHub Docs: Dependency review
Last reviewed: 19 October 2026.