A clean software composition analysis report only means something if the scan saw everything you ship. Check five things: which repositories ran, whether lockfiles were read, which ecosystems are supported, whether monorepo subfolders were included, and whether container base images were scanned. A short report with gaps is worse than a long one.
Why coverage comes before findings
SCA matches an inventory of packages against vulnerability data. If the inventory is incomplete, the matching can be perfect and the report still wrong. The npm documentation makes a related point: by default npm requires a package lock or shrinkwrap file to run an audit, and bypassing it means results may differ on every run because npm rebuilds the dependency tree each time. A lockfile is what pins the versions your build actually uses.
The five point check
- Repositories. Compare the repositories in the report to the list of repositories that deploy to production. Anything missing was not scanned.
- Lockfiles and manifests. For each project, confirm the scan used the lockfile, not only the manifest. A manifest lists version ranges. A lockfile lists the versions resolved.
- Ecosystems. List the languages in each repo, then confirm each package manager is read. Mixed repos often have a JavaScript front end, a Python service and a Java module.
- Subfolders. In a monorepo, check that nested projects appear as separate entries. A scan run from the repo root may read only the root manifest.
- Images and system packages. If you ship containers, application dependencies are only part of the inventory. Operating system packages in the base image need their own scan.
How to run the check in ten minutes
Pick three services at random. For each, open the report and find its entry. Count the packages listed, then count the packages in its lockfile with the package manager's own tooling. For npm, the npm ls command prints the installed packages in a tree, and with the all option it includes their dependencies. The numbers should be close. A large gap points to a scan that did not read the lockfile or the full tree.
# Rough package count from a lockfile project (run in the project folder)
npm ls --all --parseable | wc -l
Treat the output as a sanity check, not an exact match, since reports may count unique name and version pairs while the tree repeats shared packages.
Signs of a coverage problem
- The report has far fewer packages than the lockfile.
- Whole services have zero findings and zero packages listed.
- Only one ecosystem appears in a polyglot repo.
- No operating system packages appear for container workloads.
- The scan date is older than the last release.
Try it yourself
Click through it at your own pace, or open it full screen. Notice how the inventory comes first and the findings are attached to it afterward.
Where Safeguard fits
Safeguard includes asset discovery and SBOM generation, which helps you answer the "what exists" question before reading findings. A free scan at gold.safeguard.sh/scan shows the inventory it built.
Quick check
Is a manifest enough for an accurate scan?
Usually not. A manifest holds version ranges, while a lockfile records the exact resolved versions, so scan results from a manifest alone can differ between runs.
Do I need to scan container images separately?
Yes if you ship them. Base image packages are not in your application lockfile.
Sources
Last reviewed: 19 October 2026.
