Compare two lists: every repository in the organization, and every repository with recent scan results. The difference is your coverage gap. Explain each exclusion, such as an archived repo, in writing, and rerun the comparison monthly so new repositories do not slip through.
Why coverage is the real question
A clean scan report from ten repositories says nothing about the eleventh. Auditors who test scanning often ask for the population first: how many repositories exist, how many are in scope, and how you know. Evidence that starts from the full list is much stronger than a folder of reports.
The two lists
GitHub's REST documentation lists an endpoint for organization repositories, and endpoints for code scanning alerts and analyses per repository. GitLab and other hosts offer similar listings. The first gives you the population. The analyses list shows which repositories have had scans and when.
| List | Source | What it proves |
|---|---|---|
| Population | Organization repository listing | What exists |
| Scanned set | Code scanning analyses or your scanner's project list | What was scanned and when |
| Exclusions | A short written register | Why anything is missing |
Steps
- Export the repository list monthly with name, visibility, archived flag and last push date.
- Export the list of repositories with a scan result in the last thirty days from your scanner.
- Compare. Flag any active repository without a recent result.
- For each flag, either enable scanning or add a register entry, for example "archived, no pushes since last year, reviewed on this date".
- Include dependency scanning, not only code scanning. A repository can pass one and be missing from the other.
- File the two lists, the comparison and the register together.
Edge cases to handle
- New repositories created between runs. The monthly rerun catches them, and a policy of enabling scanning at creation prevents them.
- Forks and templates. Decide whether they are in scope and write it down.
- Repositories that hold only documentation. Still list them, and mark the reason.
- Private repositories owned by individual accounts used for work. These are often missing from organization listings, so ask the team.
What good looks like
Coverage that is 100 percent of active repositories, with a short and dated exclusion list. If coverage is lower, say so and give the plan. An honest gap with a date for closing it is better than an unverified claim of full coverage.
Also keep the scan evidence itself, see keeping SARIF results per release.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how an inventory lists every component, then think of repositories as the same kind of population.
Where Safeguard fits
Safeguard provides asset discovery, SBOM and dependency scanning and compliance and evidence automation, which help keep the population and the scanned set in one view. Try the free scan.
Quick check
Is a list of scan reports enough to show coverage?
No. Start from the full list of repositories, then show which are scanned and explain the rest.
How often should I reconcile?
Monthly is reasonable, plus whenever a new repository is created in bulk, for example after an acquisition.
Sources
Last reviewed: 19 October 2026.
