Ask about both, but start with transitive. Direct dependencies are the packages a team chose on purpose. Transitive dependencies are what those packages pull in, and they usually outnumber the direct ones. Most hidden risk sits there, so ask who owns updates, how deep the tree goes and how it is monitored.
Definitions
A direct dependency is a package named in the project's manifest, such as package.json or a requirements file. A transitive dependency is a package that a direct dependency needs, and that its own dependencies need in turn. GitHub's dependency graph documentation describes how transitive paths can be shown, with a "Show paths" option for supported ecosystems, which makes the chain visible rather than assumed.
The distinction matters in a diligence conversation because the two have different owners. A team can remove a direct dependency by changing its own code. It can only change a transitive one by upgrading or replacing its parent.
Questions for direct dependencies
- Who approved each one, and is there a written selection standard?
- Are any abandoned, archived or maintained by a single person?
- Which are vendored, meaning copied into the repository, where a scanner may not see them?
- Are versions pinned in a lockfile that is committed?
These questions reveal how deliberate the engineering culture is. A short, reviewed list with named owners is a good sign. A long list nobody can explain is not a disaster, but it tells you where effort will go after signing.
Questions for transitive dependencies
- How deep is the deepest chain, and does the team know?
- When a vulnerable package is three levels down, what is the process? Upgrade the parent, override the version, or replace?
- Does the scanner report paths, so a developer knows which direct package to touch?
- Is there a record of overrides and forced resolutions, and are they reviewed?
Overrides deserve special attention. They fix one problem and can quietly freeze a package at a version nobody revisits.
Why reachability changes the conversation
Counting vulnerable transitive packages tells you very little, because many are never called by the product. Asking whether the vulnerable function is actually reachable from the application's code turns a long list into a short one. A supplier that can answer that for its own product is ahead of one that can only show a raw count.
Try it yourself
Open the demo and compare the full list of findings with the list that remains after reachability filtering. Notice which packages drop away and which stay.
Click through it at your own pace, or open it full screen.
A short ask list
| Topic | What to request |
|---|---|
| Direct list | Manifest plus owner per package |
| Transitive depth | Dependency tree for the main product |
| Overrides | List of pinned or forced versions with reasons |
| Reachability | How the team decides what to fix first |
Safeguard offers SBOM and dependency scanning plus reachability analysis, and a free scan shows direct and transitive packages for a project you already own.
Quick check
Are transitive dependencies the supplier's responsibility?
For the product you buy or acquire, yes in practice: they ship inside it. Who bears the liability is a contract question, so ask counsel.
Can a lockfile alone answer these questions?
It answers what is installed. It does not tell you who owns the update decision or whether the code path is reachable.
Sources
Last reviewed: 19 October 2026.
