Check whether you need it at all, who maintains it, what it pulls in, whether it runs install scripts, what it does in the browser, and how you will update it. A package that ends up in a bundle runs on every visitor's device, so the bar is higher than for a build-only tool.
The checklist
| Check | Question to answer |
|---|---|
| Need | Can a built-in browser feature or ten lines of your code do this? |
| Ownership | Is there an active maintainer or organization, and a clear repository? |
| Size of tree | How many transitive packages come with it? |
| Install scripts | Does it run code at install time? |
| Browser behavior | Does it make network requests, read storage or touch forms? |
| License | Does it fit your distribution? |
| Advisories | Any known vulnerabilities in the version you would pick? |
| Update path | Who will bump it, and how will you hear about issues? |
How to check each one
Need. Every package is permanent maintenance. Prefer platform features where they exist.
Ownership. Look at the repository's recent activity, the number of maintainers and whether releases come from a consistent source. A single unknown maintainer on a package that touches form data deserves more caution.
Tree size. Run a dry install and list the resulting tree. A tiny helper that brings in dozens of packages multiplies your exposure. The package lock records each one with version and integrity hash, per the npm docs.
Install scripts. npm can run lifecycle scripts for dependencies, and the ignore-scripts setting stops them. See do npm install scripts run for dependencies.
Browser behavior. Read the source or the docs for network calls, analytics, and access to storage or cookies. A UI component should not talk to the internet.
Advisories. Run a dependency scan on the candidate version before you commit to it. npm audit reports known vulnerabilities for a tree that has a lockfile.
Update path. Decide how you will learn of new versions and fixes, and who owns the bump.
A lightweight approval flow
- The developer fills a three line note in the pull request: why, alternatives, what it adds.
- CI runs the dependency scan and comments on new findings.
- A reviewer checks the tree size and install scripts.
- The lockfile change is part of the review, so the new packages are visible.
Build or buy an internal curated registry if you want a central allowlist.
Red flags
- A package name that is one character off from a popular one.
- A brand new package with a handful of downloads asking for broad access.
- A release that changes ownership or adds install scripts without explanation.
- Code that downloads and runs further code at runtime.
Where Safeguard fits
Safeguard's policies and gates can block a pull request that introduces a risky dependency, alongside SBOM and dependency scanning. A free scan is at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a new dependency can be checked before merge.
Quick check
Is a popular package always safe to add?
No. Popularity helps, but compromised maintainer accounts and bad releases have hit popular packages. Pin the version and scan it.
Does npm audit check a package before I install it?
It checks a dependency tree and lockfile for known advisories, so add the candidate in a branch and run it there.
Sources
- npm Docs, package-lock.json: https://docs.npmjs.com/cli/v10/configuring-npm/package-lock-json
- npm Docs, npm audit: https://docs.npmjs.com/cli/v10/commands/npm-audit
- npm Docs, npm ci: https://docs.npmjs.com/cli/v10/commands/npm-ci
Last reviewed: 19 October 2026.
