Scanner coverage is the share of in-scope repositories that had a successful, meaningful scan within an agreed window, such as seven days. Count repos from your source host as the denominator, not from the scanner, or you will miss the ones with no scan at all.
Define the numerator and denominator
Denominator: all active repositories that deploy or ship code, taken from the source host API or an asset inventory. Exclude archived and documentation repos, and record why.
Numerator: repositories with a scan that completed successfully in the window, covered the right scan types, and ran on the default branch or a release branch.
A scan that ran with an empty scope, or that failed quietly, should not count.
Four coverage numbers worth tracking
| Metric | Question it answers |
|---|---|
| Onboarded | Does the repo call the shared pipeline at all? |
| Fresh | Did a scan complete in the last seven days? |
| Complete | Did it run every required scan type (dependencies, secrets, code)? |
| Enforced | Does a failing result block merge or deploy? |
A repo can be onboarded and fresh, yet not enforced. Showing the four as a funnel tells you where the drop is.
Where to get the data
Your source host and scanner both have APIs. For example, GitHub exposes code scanning alerts for an organization at GET /orgs/{org}/code-scanning/alerts, which lists alerts on the default branch for eligible repositories, and for a repository at GET /repos/{owner}/{repo}/code-scanning/alerts. The organization endpoint needs an owner or security manager. Filters include state, severity and tool name, which lets you check that a particular tool reported.
Note that alert lists show findings, not absence of a scan. A repo with zero alerts could be clean or unscanned. For freshness you need scan run records from your pipeline or scanner.
Build the report
- Pull the repo list nightly and store it with owner and criticality.
- Pull latest scan time and type per repo from the scanner.
- Join, compute the four numbers, and break them down by team.
- Flag repos with no scan in 14 days for follow up.
- Publish one page that anyone can read.
Avoid gaming
A target of 100 percent coverage invites trivial scans. Pair coverage with a quality check, such as the number of dependencies found per repo compared with the lockfile, so an empty inventory stands out. See coverage matrix before you retire a scanner for a related method.
Try it yourself
The continuous monitoring demo shows how ongoing scan status looks across assets. Look for what a stale asset looks like.
Click through it at your own pace, or open it full screen.
Quick check
Is zero alerts a sign of good coverage?
No. Zero alerts can mean a clean repo or no scan. Check scan freshness separately.
What coverage target is sensible?
Set it per tier. Aim for near complete on production services first, and treat the long tail as a later wave.
Safeguard includes asset discovery and continuous scanning, which can feed a coverage view, and the free scan at gold.safeguard.sh/scan shows a single repo result.
Sources
- GitHub Docs: REST API endpoints for code scanning, fetched 19 October 2026
Last reviewed: 19 October 2026.
