It should, and you can test it in five minutes. Ask the demo to show a vulnerable package that you never declared yourself, then ask for the chain of packages that brought it in. If the tool lists only top-level dependencies, it is missing most of what ships.
Definitions
A direct dependency is a package your project declares. A transitive dependency is a package that one of your dependencies needs, and so on down the chain. Most of the code in a modern application sits in the transitive layer, which is why scanners that stop at the first level can look clean while being wrong.
A lockfile records the exact versions that were resolved, including transitive ones. Without it, a scanner can only guess at what a build would have pulled in.
The five minute test
- In your own repo, run the package manager's own command to list the dependency tree. Save the output.
- In the demo, ask the vendor to show the component inventory for the same repo.
- Compare counts. The scanner's total of unique components should be close to the tree you saved. Small differences have reasons, such as dev dependencies or optional packages. Large ones need an explanation.
- Pick a transitive package with a known advisory. Ask the demo to show it.
- Ask for the path from your declared dependency down to that package.
What a good result looks like
| Check | Good sign | Warning sign |
|---|---|---|
| Inventory size | Close to your own tree | A fraction of it |
| Transitive findings | Shown with the same detail as direct ones | Hidden behind a filter or missing |
| Path | Full chain, clickable | Only the package name |
| Version source | Taken from the lockfile | Taken from a range in the manifest |
The last row matters. A manifest might say "any version above 2.0". The lockfile says "2.4.1". The scanner should judge 2.4.1, because that is what runs.
Why the path matters
Developers cannot fix a transitive finding directly. They upgrade the direct dependency that pulls it in, or add an override. The path tells them which of those to try. A finding without a path is a to-do item without instructions, and it tends to sit in the queue.
Ask one more question: if two different direct dependencies bring in the same vulnerable package, does the tool show both paths? Fixing one path leaves the other, and a scanner that shows only one will mislead you.
Edge cases to bring up
- Monorepos with several lockfiles.
- Packages pinned to a git commit instead of a version.
- Vendored code copied into the repo with no manifest.
These are not trick questions. They are what your repositories contain. Ask how each is handled, and test at least one on your messiest repo.
Where Safeguard fits
Safeguard's SBOM and dependency scanning builds an inventory of components, and reachability analysis helps separate transitive packages your code calls from those it never touches. The demo below shows an inventory you can browse.
Try it yourself
Click through it at your own pace, or open it full screen.
Look for how the inventory separates what you declared from what came along with it.
Quick check
What if my repo has no lockfile?
Then the scanner has to infer versions, and results will be less certain. Ask how it handles this and consider adding a lockfile, which helps your builds as well.
Are dev dependencies in scope?
They can be, but they should be labeled. A flaw in a test tool matters differently from one in a production library.
Last reviewed: 19 October 2026.
