Track three numbers: the share of repositories with a scan, the share of pull requests that got a check, and the age of the latest full scan. A static analysis tool only protects code it actually sees, so coverage gaps often matter more than engine differences.
The quiet failure
Teams buy a tool, set it up on the first ten repositories, and report success. A year later there are two hundred repositories, new ones appear weekly, and nobody knows how many are scanned. This is common and avoidable.
Ask during evaluation how the tool helps you answer, at any moment, which repositories are not covered.
Three coverage numbers
Repository coverage. Repositories with a recent successful scan divided by all active repositories. The denominator comes from your source host, not the scanner, otherwise you only count what you already know about.
Change coverage. Pull requests that ran the check divided by all merged pull requests, for repositories in scope. Low numbers reveal bypasses, skipped checks and repositories where the integration broke.
Freshness. For full scans, the age of the latest successful scan per repository. A repository scanned once, eight months ago, is not covered in any meaningful way.
Add a fourth if you can: language coverage. A repository with code in three languages, where the tool analyses two, is only partly covered.
What the tool should provide
- An inventory view that lists repositories from your source host and marks scanned and unscanned ones.
- Detection of new repositories, with an option to enable scanning by default.
- Alerts when a scan fails repeatedly or when a repository stops reporting.
- Reporting on which languages and files were analysed or skipped, including parse failures. Silent skips are the worst kind of gap.
- Export of these numbers, so you can put them in a monthly report.
Ask a vendor to show the parse failure view on a repository with a messy build. A tool that quietly analyses half the files and reports a clean result is dangerous.
How to find repositories you do not know about
Compare the scanner's list with your source host's full list, including archived and forked ones. Check team and personal namespaces, and any second source host from an acquisition. Shadow repositories exist in most organisations.
Set targets and owners
Write targets that you can defend: all production repositories scanned weekly or more often, pull request checks on all repositories with deployments, and no unexplained failures older than a week. Give someone ownership and a monthly review.
Required checks
Make the scan a required status check on protected branches. Otherwise change coverage depends on goodwill. Confirm that a skipped check cannot pass silently, a known weakness in some configurations.
Try it yourself
Click through it at your own pace, or open it full screen. Notice how ongoing monitoring surfaces what changed since the last scan.
Quick check
What is the denominator for repository coverage?
All active repositories on your source host, not just the ones the scanner already knows.
Is a clean result on a repository always good news?
Not if files were skipped. Check parse failures and analysed file counts first.
Safeguard's asset discovery and continuous scanning are generally available, with a free check at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
