Yes, it can be. Every new dependency adds code, maintainers and publish paths you did not choose. Growth is not wrong, but it should be visible. Compare the dependency list before and after an update, and ask whether each new package is needed and whether it belongs in production.
Why it matters
The OpenSSF Concise Guide opens with the point that every new dependency increases the attack surface, because a subversion of the new dependency or its transitive dependencies may subvert the system. It lists Consider Necessity as the first rule: evaluate whether the dependency can be avoided by using existing components.
Its Practical Testing section asks about Dependency Impact: does the package add unexpected or unnecessary indirect dependencies in production, for example packages needed only for development or tests?
How to see what an update adds
- Before you upgrade, record the full dependency tree with your package manager's list command, or export an SBOM.
- Upgrade in a branch and record the tree again.
- Diff the two lists. The deps.dev API can also return the dependency graph for a specific version, which lets you compare versions without installing.
- For each new package, run the identity check: owner, creation date, fork status, similar names.
- Check whether it is a runtime or development dependency, and whether it has install scripts.
| New package type | Question to ask |
|---|---|
| Runtime dependency | Does the feature justify it? |
| Dev dependency leaked into runtime | Can the maintainer fix the metadata? |
| Package with install script | Why does it need to run code on install? |
| Package from an unknown maintainer | Does it pass the basic identity and maintenance checks? |
| Replacement for an old dependency | Is the old one gone, so growth is neutral? |
Judge the trade
A new dependency can be a good trade if it replaces custom code you would maintain badly, or if it comes from a well maintained project. It is a poor trade if it exists for a small convenience. The Guide's suggestion to avoid hype driven choices applies here as well.
When a dependency of yours keeps growing its tree, tell the maintainers. The Guide notes it is worth asking whether they would be willing to fix unnecessary production dependencies.
Make it a gate
Add a check to pull requests that touch lockfiles. It prints the new packages and their depths. A reviewer sees them before merge. For large upgrades, require a short note explaining why the added packages are acceptable.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how direct and transitive packages appear in one inventory, which is the view you diff before and after an update.
Where Safeguard fits
Safeguard provides SBOM and dependency scanning, reachability analysis and policies and gates for pull requests. A free scan is at gold.safeguard.sh/scan.
Quick check
Is a bigger tree always worse?
Not always, but each added package is more to trust. Make the growth deliberate.
Do dev dependencies matter?
Yes, because they run on developer machines and in CI. They matter less if they never reach production, but they still touch your secrets.
Sources
Last reviewed: 19 October 2026.
