Weigh signals by blast radius. Packages that run during install or build, such as plugins, CLIs and CI helpers, can reach source code, tokens and the build output, so review practice, provenance and install behavior matter most for them. For a small runtime helper, maintenance and known flaws usually matter more.
Start with what the package can reach
The same signal means different things depending on the role. A single maintainer on a string formatting helper is a modest concern. A single maintainer on a build plugin that runs in CI with deploy credentials is a larger one, because a bad release would execute in a privileged place.
Sort your dependencies into three rough tiers.
| Tier | Examples | What it can reach |
|---|---|---|
| Build and CI | Plugins, task runners, CLIs, CI actions | Source, tokens, artifacts |
| Runtime, handles untrusted input | Parsers, HTTP clients, template engines | Your running process and user data |
| Runtime, pure helpers | Formatting, small utilities | Little beyond your process |
Signals to weight by tier
For build and CI packages, prioritize:
- Install-time behavior. npm runs preinstall, install and postinstall scripts during install, and a new script is a flag. The ignore-scripts setting can turn them off.
- Build attestations. npm provenance and PyPI attestations tie an artifact to a source and workflow.
- Review and branch protection. The Scorecard Code-Review and Branch-Protection checks speak to how hard it is to add a bad change.
- Release age. npm min-release-age installs only versions older than a number of days, which gives the community time to notice problems.
- Pinning. The Scorecard Pinned-Dependencies check treats dependencies pinned to a hash as more resistant to compromise.
For runtime packages that handle untrusted input, prioritize security response speed, a reporting policy, and the current advisory status of your version. For pure helpers, a light check of identity and maintenance is usually enough, and finished small utilities may not need regular releases.
A tiered review in practice
| Tier | Suggested depth |
|---|---|
| Build and CI | Full identity, review, provenance and install behavior check; pin; wait before upgrade |
| Untrusted input | Identity, maintenance, advisory history, reporting policy |
| Pure helpers | Identity and a maintenance glance |
Record the tier with each dependency. When a package changes role, for example a helper added to a build script, move it up a tier.
The common mistake
Teams often apply one flat checklist to everything, which wastes time on helpers and under-reviews tools that touch secrets. The Concise Guide itself says even great open source may do poorly on some questions, so a score alone cannot set the tier. Your use of the package does.
Try it yourself
Click through it at your own pace, or open it full screen. It shows how knowing what your code actually reaches changes what deserves attention first.
Where Safeguard fits
Safeguard provides reachability analysis, SBOM and dependency scanning, and policies and gates, so priority can follow how a component is used. A free scan is at gold.safeguard.sh/scan.
Quick check
Are CI actions dependencies too?
Yes. They run in your pipeline, often with secrets, and deserve the same review as code you ship.
Should I disable install scripts everywhere?
Disabling them is a reasonable default for many projects, but some packages need them. Allow those deliberately.
Sources
- npm Docs: scripts
- npm Docs: config
- npm Docs: Generating provenance statements
- PyPI Docs: Digital attestations
- OpenSSF Scorecard check documentation
- OpenSSF Concise Guide for Evaluating Open Source Software
Last reviewed: 19 October 2026.
