There is no universal limit, but every indirect dependency is code you now trust, maintained by people you did not choose. Measure the tree before you add a package, compare it with alternatives that do the same job, and set a team threshold that triggers a closer look.
Why the tree matters
When you install one library, you install its dependencies, theirs, and so on. Each package is a possible source of vulnerabilities, abandoned code, or a compromised publisher. The more of them there are, the more you must monitor.
The OpenSSF evaluation guide asks you to check the impact: look for unnecessary indirect production dependencies, such as development or test only packages that ended up in the production list. Those add risk with no benefit.
deps.dev is a handy place to see the shape. It builds a full dependency graph for each package and supports Cargo, Go, Maven, npm, NuGet, PyPI and RubyGems.
How to measure it
- Look up the candidate on deps.dev and note direct and indirect counts.
- Or install it in a scratch project and run your package manager's tree or list command.
- Record three numbers: direct dependencies, total indirect dependencies, and the number of distinct maintainers or organizations behind them if you can tell.
- Note anything with install scripts, native code or unusual size.
- Repeat for one or two alternatives.
A comparison table to fill in
| Candidate | Direct | Indirect | Install scripts | Notes |
|---|---|---|---|---|
| Option A | ||||
| Option B | ||||
| Write it yourself | 0 | 0 | none | Your maintenance cost |
The last row is real. Sometimes the cheapest tree is no tree.
Setting a threshold
Pick a rule that matches how you work, and write it down. Examples that work in practice:
- Any new package with more than a set number of indirect dependencies needs a second reviewer.
- A package that adds more indirect dependencies than the rest of the service combined needs a short written reason.
- A new package that pulls in native code or install scripts goes through a sandbox test.
The exact numbers are yours to choose based on your risk. What matters is that the rule triggers a conversation instead of an automatic merge.
Cutting the tree down
- Prefer libraries that do one thing and depend on little.
- Use a standard library feature when it covers the need.
- Check whether a heavy package offers a lighter entry point that skips optional parts.
- Remove packages that shipped as development tools but sit in production lists.
- Re-run the measure after upgrades. Trees grow over time.
What size does not tell you
A small tree is not proof of quality, and a large tree is not proof of danger. A well known framework may bring many packages that are each carefully maintained. Size is a cost signal. It tells you where to look, and it multiplies the importance of monitoring, since you will be told about vulnerabilities in packages you never chose.
Try it yourself
Open the demo and look at how one inventory shows both direct and indirect packages, then consider how many of those rows you chose on purpose.
Click through it at your own pace, or open it full screen.
Quick check
Do development dependencies count toward production risk?
Only if they end up in the production package. The OpenSSF guide asks you to check for test or development only packages in the production dependency list.
Is a bigger tree always worse?
No, but it is a cost. It means more code to trust and monitor, so ask whether the benefit justifies it.
Safeguard's SBOM and dependency scanning inventories direct and indirect packages so you can see the real size of your tree. Try the free scan.
Sources
Last reviewed: 19 October 2026.
