Not one by one, but they cannot be ignored. Approve direct dependencies by hand or tier, and govern transitive ones with rules: allowed licenses, known malicious package blocks, vulnerability response times and limits on suspicious changes. The direct choice decides what you inherit.
Why one by one does not work
A single direct package can pull in dozens of others. Reviewing each manually would stall teams and still miss changes when a new version arrives. But treating transitive packages as invisible leaves a gap, since many serious supply chain problems arrive through packages nobody chose.
Direct versus transitive
| Direct | Transitive | |
|---|---|---|
| Who chose it | A developer | The package you chose |
| Approval | Intake and tier | Rules applied automatically |
| License check | Reviewer confirms | Automatic against allowed list |
| Vulnerability response | Owner upgrades | Owner upgrades parent or overrides version |
| Visibility | Manifest | Lockfile or SBOM only |
Rules that work on inherited packages
- License rules apply to everything in the resolved tree for products you ship.
- Block known malicious packages at the proxy, no matter how they were reached.
- Apply vulnerability response times to the whole tree, with reachability used to set priority.
- Flag newly added transitive packages in a pull request. A lockfile change that adds forty packages deserves a look.
- Prefer direct packages with a small dependency tree when two options are equal.
How to act on a vulnerable transitive package
- Find which direct dependency brings it in. Package manager commands can print the path.
- Check whether a newer version of the parent fixes it.
- If not, use your package manager's override or resolution feature to force a patched version, then run tests.
- If the parent is abandoned, plan to replace it, and record an exception with an expiry until then.
Overrides are a stopgap. They can break the parent in ways tests may not catch, so note them in the repository and review them when the parent updates.
Pin with a lockfile
A committed lockfile with integrity hashes fixes the exact transitive set for each build. Without it, two builds a day apart can differ. Make CI install strictly from the lockfile so unreviewed versions do not appear.
Try it yourself
Click through it at your own pace, or open it full screen. Many inherited findings sit in code your application never calls, and this shows how to tell.
Quick check
Do licenses of transitive packages matter?
Yes. If the code ships in your product, its license applies whether you chose it or not.
Is overriding a transitive version safe?
It is a temporary measure. Test it and record it, and remove the override once the parent catches up.
Safeguard scans dependencies and builds SBOMs, runs reachability analysis, and applies policies and gates on pull requests, so the rules in this post can be checked automatically. Autonomous fix PRs are off by default, with every category on Manual. You can run a free scan at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
