List every dependency file in your repositories, then compare that list with the files each scanner reports reading. Any file in the first list and not in the second is a blind spot. Most missing findings between two tools trace to a file one of them never opened.
Why coverage is the first thing to check
Before you argue about advisory data, make sure both tools looked at the same thing. A scanner can only report on files it recognizes, finds and parses. If your repository has a Gradle module nested three folders down, a Python project in a subfolder, or a lockfile with an unusual name, one tool may skip it silently.
A clean result from a tool that never read the file is not a clean result.
Step 1: inventory your dependency files
Search the repository for manifests and lockfiles across your ecosystems. Typical examples include package.json and its lockfile for npm, pom.xml for Maven, requirements files and pyproject.toml for Python, go.mod for Go, and Gemfile with its lock for Ruby. The pip-audit README, for example, says that for project paths it currently supports only pyproject.toml and pylock files, which shows how a tool's accepted inputs can be narrower than your repository.
Write the full path of each file in a list. Include nested directories, test fixtures and example projects, then mark which ones ship.
Step 2: get each scanner's file list
Many tools can print or log the files they processed, or the projects they detected. Look for a verbose or debug option, a scan summary, or a project list in the console. If a tool gives no such output, create a canary instead: add a dummy dependency with a known advisory to each manifest in a branch and see whether the tool reports it.
Step 3: compare
| In your inventory | In scanner A | In scanner B | Meaning |
|---|---|---|---|
| Yes | Yes | Yes | Covered by both |
| Yes | Yes | No | B has a gap here |
| Yes | No | Yes | A has a gap here |
| Yes | No | No | A shared blind spot |
| No | Yes | No | A read something you did not list, check your inventory |
The last row matters too. A tool that reads files you forgot, such as an old example folder, explains extra findings.
Step 4: close the gaps
- Configuration. Many gaps are fixed by pointing the tool at the right directory or enabling the ecosystem.
- File naming. Rename or declare nonstandard files so the tool recognizes them.
- Unsupported formats. If a tool cannot read a format, use another method for that part, or generate an SBOM from the build and scan that.
- Generated files. If a lockfile is produced during the build and never committed, scan the build output instead.
Step 5: keep it from drifting
Add the inventory check to CI. A simple script that lists dependency files and compares with the previous run will tell you when a new manifest appears that no scanner covers. New services often arrive with new file types, and coverage rots quietly if nobody checks.
Beyond the repository
Source files are not the whole story. Container images can carry packages that no manifest declares. If you ship images, scan the image too, and compare the image inventory against the source inventory.
Quick check
Is a clean scan trustworthy?
Only for the files it read. Confirm coverage first.
What if my scanner cannot list the files it processed?
Use a canary: add a dependency with a known advisory to each manifest on a branch and see whether it is reported.
Sources
Last reviewed: 19 October 2026.
