Take a lockfile, pick five packages that are not in your manifest, and check that the tool reports each one with the path that brought it in. If it lists only what you declared, it is reading your wish list, not your build. This test takes under an hour.
Why transitive coverage matters
A direct dependency is one you chose. A transitive dependency is one your dependency chose. The npm documentation describes the lockfile as the exact tree generated, listing every installed package keyed by location, not only those in package.json. That is the tree you ship, so that is the tree a scanner should read.
The NTIA minimum elements make the same point for SBOMs: a good SBOM contains primary components with their transitive dependencies.
The five package test
- Open the lockfile for a service you know.
- Choose five packages deep in the tree that do not appear in your manifest.
- Scan the repository with the tool under test.
- Search the results for each of the five.
- For each, check the version matches the lockfile and a dependency path is shown.
Score it out of five. Anything below five tells you something.
What a good path display looks like
A useful result says: package X at version Y, introduced by A, which was introduced by B, which is your direct dependency. A code host's dependency graph docs describe a similar idea, a "Show paths" view of the transitive route, for ecosystems that support it. The path matters because the fix is often to upgrade B, not X.
Common reasons a tool misses
- It reads only the manifest and ignores the lockfile.
- The lockfile format or version is not supported.
- The project has no lockfile, so the tool has to guess at resolution. Guesses can differ from what CI installs.
- Dependencies are resolved at build time by a tool the scanner does not run.
If the test fails, ask whether a configuration change fixes it, such as pointing at the lockfile or running a resolve step first.
Test a second ecosystem
Repeat with a different package manager. Coverage is rarely even. A tool strong on one ecosystem may be shallow on another, and you ship both.
Test a monorepo layout
Put the lockfile in a subfolder and see whether the tool finds it. Many do, some do not. See monorepo and container coverage checks for more.
Safeguard's SBOM and dependency scanning is built to read the full dependency tree. You can run the five package test on your own repository with the free scan at https://gold.safeguard.sh/scan.
Quick check
What if my project has no lockfile?
Add one and commit it. Without it, the tool and your CI may resolve different versions, and any result is only a guess.
Click through it at your own pace, or open it full screen.
Sources
- npm Docs, package-lock.json
- GitHub Docs, About the dependency graph
- NTIA, The Minimum Elements For a Software Bill of Materials
Last reviewed: 19 October 2026.
