List every manifest and lockfile the repository tracks with git ls-files, then compare that list to the files your scanner says it analysed. Any file on the first list and not the second was skipped. This takes minutes and catches nested projects, odd names and ignored folders.
Why skips happen silently
Scanners often have default ignore rules, depth limits or file name patterns. A nested services/billing/requirements.txt or a requirements-prod.txt may fall outside them. The scan finishes with no error, and the results look normal. A failure that produces no output is the hardest to notice.
Step 1: list what exists
The git documentation describes git ls-files as showing information about files in the index and working tree. Use it to list tracked files by name.
git ls-files | grep -E '(^|/)(package-lock\.json|yarn\.lock|pnpm-lock\.yaml|requirements.*\.txt|Pipfile\.lock|poetry\.lock|go\.mod|Cargo\.lock|pom\.xml|build\.gradle(\.kts)?|Gemfile\.lock|composer\.lock|packages\.lock\.json)$' | sort > manifests-present.txt
Adjust the pattern to your ecosystems.
Step 2: list what was scanned
Export the scanner's list of analysed files, which many tools provide in JSON or verbose output. Reduce it to one path per line and sort it into manifests-scanned.txt.
Step 3: diff
comm -23 manifests-present.txt manifests-scanned.txt
Every line printed is a manifest the scanner did not report on.
Step 4: classify each skip
| Skipped file | Likely reason | Fix |
|---|---|---|
| Nested project folder | Depth or workspace rules | Configure scan roots |
| Unusual file name | Pattern match | Add the name to config |
| Test or example folder | Default exclusion | Decide if it matters |
| Lockfile only, no manifest | Parser needs both | Add the manifest |
Some skips are right. An example folder may not ship. Make that a decision, not an accident.
Step 5: keep it running
Put the diff in CI as a nonblocking report first. Once the list is clean, make any new unscanned manifest a failing check. That turns coverage from a one off audit into a standing control. See check every repository is scanned: coverage evidence for the repository level version.
Also look for manifests that are not tracked, such as generated ones, with the other-files option in git ls-files, since the build may create dependency files at run time.
Safeguard offers dependency scanning and a free scan at gold.safeguard.sh/scan. Whatever tool you use, keep a file level diff.
A worked example
Imagine a repository with three tracked manifests: a root package-lock.json, services/billing/requirements.txt and tools/report/go.mod. The scanner reports on the first and the third only. The diff prints services/billing/requirements.txt. You open the scanner configuration and find a rule that stops descending past the second folder level. You raise the limit, rescan, and the billing dependencies now appear, along with several findings nobody had seen. That is the typical outcome: the first diff is uncomfortable, and every one after it is quiet.
Write down the date and the result, because the history of the diff shows whether coverage is improving.
Quick check
Does this work for non-Git repositories?
The idea does. Use find or your version control's listing command instead.
Should every skipped file be fixed?
No. Decide for each. Skips that are intended should be written down.
Sources
Last reviewed: 19 October 2026.
