Compare what was scanned before the move with what is scanned after it, using three counts: manifests and lockfiles found, projects reported, and open findings carried over. Every difference needs an explanation. Keep the old scans running until the numbers match, because a quiet drop in coverage looks identical to a clean result.
Why coverage drops quietly
Scan setups are often tied to repository settings: a connected repo, a default path, an integration token. When ten repositories become one, the new repository may be scanned at its root only, so packages under services/ are never seen. The dashboard shows green, because green means no findings in what was scanned.
Dependency update tools have the same trait. Dependabot's reference says the directories or directory option is required and defines where manifests live, and that without it Dependabot cannot create version update pull requests. A configuration copied from a single-package repo will name the root only.
Build the before picture
Before you cut over, record for each source repo:
- the manifest and lockfile paths scanned
- the number of components in the latest software bill of materials
- the count of open findings by severity
- the ecosystems covered (npm, Maven, Python and so on)
Build the after picture
After the import, find every manifest and lockfile in the new repo. Our guide to finding every lockfile in a monorepo shows how. Then compare.
| Check | Before | After | Explain differences |
|---|---|---|---|
| Lockfiles found | 10 repos, 14 files | 14 files | Should match |
| Components in SBOM | Sum of ten | One merged | Duplicates may collapse |
| Open findings | Sum of ten | Count in new | Fewer is fine if duplicated |
| Ecosystems | npm, Maven, Python | All three | Missing one is a gap |
The numbers above are an illustration of the layout, not data.
Explaining the differences
A lower component count can be legitimate when the same package appeared in several repos and now appears once. A missing ecosystem is a gap. A lockfile that exists but is not reported usually means the scan path or an exclude rule is wrong. For exclusions, see what to exclude from a dependency scan.
Keep the old scans for a while
Run both for a short overlap. Retire the old scans only after the new coverage statement is written. A template is in scan coverage statement: what to attach to every scan report.
Try it yourself
Click through it at your own pace, or open it full screen.
Open the inventory and look at how components are grouped, then think about which of your lockfiles would appear there.
Safeguard's SBOM and dependency scanning produce the inventory for each repository, and you can try a free scan at gold.safeguard.sh/scan.
Quick check
Is a clean scan after the move good news?
Not until you know what it covered. Confirm the lockfile and project counts first.
How long should the old scans keep running?
Until the new scan reports every manifest the old ones did, with differences explained.
Sources
Last reviewed: 19 October 2026.
