Ask the demo for a list of files and folders the scan did not read, and the reason for each. Then compare it with what git says is in your repository. A clean result means little until you know what was left out.
The silent gap
Scanners report what they found. They are less eager to report what they could not see. A manifest in an unexpected folder, a lockfile in an unsupported format, or a vendored library with no package metadata can all pass through without a warning.
A repository with no findings is good news only if the scan covered the repository. Otherwise it is an empty result.
Build your own file list first
Before the demo, make a list of every dependency file in the repo. A simple approach is to list tracked files with git and filter by the names of manifests and lockfiles used by your languages. Save the list.
Include:
- Package manifests and lockfiles for each language.
- Container build files.
- Build configuration that declares dependencies.
- Any vendored directories.
In the demo
- Ask for the list of files the scan used. Compare it line by line with yours.
- Ask for the list of files it skipped, with reasons.
- Pick one file on your list that is missing from both lists. This is the interesting case.
- Ask whether the tool can warn you about unrecognized files in future scans.
Common reasons for skipped files
| Reason | What to do |
|---|---|
| Unsupported ecosystem or format | Ask for the roadmap, or plan a second tool |
| Excluded by default, such as test or example folders | Decide whether you want them in scope |
| Too large or timed out | Ask about limits and settings |
| No lockfile present | Add one, or accept lower certainty |
| Path ignored by a rule | Check the rule is intentional |
Some exclusions are sensible. Example code in documentation folders may not deserve findings. The key is that the exclusion is visible and chosen by you.
Coverage as a number
Once you have both lists, you can compute a simple figure: files read divided by dependency files you know exist. Say it out loud in the demo. "It read nine of twelve, and here are the three it missed" is a precise, useful statement. Ask the vendor to react to it.
Repeat the exercise for each of your three repositories if you can. Coverage often varies sharply between a new service and an old one.
What to put in the follow-up email
Ask in writing how unrecognized files are reported, whether coverage gaps appear in the interface, and whether the tool can fail a build if its coverage drops below a level you set. These answers tell you whether coverage is a managed property or a hope.
Where Safeguard fits
Safeguard's asset discovery and SBOM and dependency scanning are GA capabilities aimed at building a complete inventory. Run the free scan at gold.safeguard.sh/scan and compare the files read with your own list.
Quick check
Is a skipped file always a problem?
No. Some are rightly out of scope. The problem is a skipped file nobody knew about.
How do I find manifests the scanner might miss?
List tracked files with git, filter by manifest and lockfile names for each language, and compare with the scanner's list.
Last reviewed: 19 October 2026.
