Ask vendors how their tool finds repositories, services and components you did not tell it about, how it shows coverage as a number, and what it cannot see. A good answer names the sources it reads and the gaps. A weak one says "complete visibility" and offers no way to check.
Why coverage is the first question
Every other capability depends on seeing the asset. A scanner cannot report on a repository it never learned about. Teams often discover that the estate they think they have and the estate they actually have differ, particularly with older services and forks.
Ten questions to adapt
Discovery
- Which sources does the product read to find assets: source control, CI, container registries, cloud accounts, package registries?
- Does it find repositories that were not explicitly added, and how often does it rescan for new ones?
- How does it treat archived, forked and mirrored repositories?
Components
- Which package ecosystems and file types does it read, listed by name?
- Does it capture transitive dependencies, and to what depth?
- How does it record components that are copied into a repository rather than declared in a manifest?
Coverage proof
- How is coverage reported: percentage of known repos scanned, last scan time, failures?
- How does it show what it could not scan, and why?
- Can we compare the inventory against an independent list, such as our own source control export?
Output
- In which machine-readable formats can we export the inventory, and does the export keep ownership information?
What to look for in answers
| Signal | Why it matters |
|---|---|
| Named sources and ecosystems | Shows the claim can be checked |
| A coverage metric | Lets you track progress over time |
| A list of unscanned items with reasons | Honest about gaps |
| Ownership attached to assets | Findings get routed to someone |
| Open export formats | Lets you reconcile and avoid lock-in |
A quick coverage test for the trial
- Export a list of repositories from your source control system.
- Run the vendor's discovery with read-only access.
- Compare the two lists and note differences in both directions.
- Pick five repositories at random and check that their ecosystems and key dependencies appear correctly.
- Pick one repository with an unusual build and see what the tool says about it.
Use least privilege for any access you grant, and review the permissions with your security team before the test.
A worked example: reconciling two lists
A team exports 412 repositories from source control. The vendor's discovery trial reports 365 repositories. The team builds a reconciliation table.
| Category | Count | Explanation |
|---|---|---|
| In both lists | 360 | Expected |
| In source control only | 52 | 38 archived, 9 empty, 5 private with no access granted to the tool |
| In the vendor list only | 5 | Forks the team did not know about |
| Scanned successfully | 340 | Of the 365 |
| Not scanned, reason shown | 25 | Unsupported build tool, empty manifest, access error |
The numbers are illustrative, but the pattern is real. The reconciliation exposes three things: archived repositories that can be excluded on purpose, repositories the tool could not read, and forks nobody tracked. A good vendor shows the reasons for every gap. A weak one shows a single coverage percentage with no detail.
Component level checks
Inventory is not just a list of repositories. Test the component level too:
- Choose three repositories in different ecosystems.
- Generate your own list of declared dependencies from the lockfile using the ecosystem's own tools.
- Compare it with the vendor's inventory, including transitive dependencies.
- Check a vendored or copied library. Does the tool notice it, or only declared packages?
- Check a container image built from one of the repositories. Does the inventory link the image and its source?
Record differences in both directions.
Questions about change over time
- How does the inventory update when a repository is renamed, moved or archived?
- How is history kept, so you can answer what you ran on a given date?
- Can you ask what depended on a given package version at a past date?
- How fast does a new repository appear after creation?
The last two questions matter most when a new advisory arrives and you need to answer "are we affected" quickly.
Ownership data
An inventory without owners creates findings without recipients. Ask where ownership comes from: code owner files, team membership, a manual field, or an import from another system. Ask what happens when an owner leaves the company and how orphaned assets are shown.
What not to expect
No tool sees everything. Shadow repositories, personal accounts and systems outside the connected platforms will be missed. A strong answer admits this and explains how you can reduce it, for example by requiring that organization accounts own all repositories.
Try it yourself
Click through it at your own pace, or open it full screen. Look for the ecosystems and components it lists, and think about which of your own repos would not be covered.
Quick check
Is inventory the same as scanning?
No. Inventory records what exists. Scanning checks it for problems. Coverage depends on both.
How do we check coverage objectively?
Compare the tool's list with an independent export from source control and investigate every difference.
What should we do with repositories the tool cannot scan?
Record each with its reason, then decide whether to fix access, add support, or exclude it on purpose with an owner and a review date.
Safeguard's GA capabilities include asset discovery and SBOM and dependency scanning, so these ten questions apply to it too. The free scan at https://gold.safeguard.sh/scan is a way to check output on one repo.
Last reviewed: 19 October 2026.
