Onboard in waves of 20 to 50 repositories, automate the connection step through an API or app install, verify each wave against a known list, and hand findings to owners before starting the next wave. Never connect everything at once, because the first scan result floods people before routing works.
Before wave one
Settle three things first.
- A repository list you trust. Pull it from your source control platform, not from memory. This is your denominator for coverage.
- An ownership mapping. Even a rough one. See ownership routing options.
- A baseline policy in report mode. No blocking yet.
Choose the waves
| Wave | Contents | Why |
|---|---|---|
| 0 | 3 to 5 volunteer repos | Shake out configuration |
| 1 | 20 to 50 repos from friendly teams | Prove routing and noise handling |
| 2 | Customer facing and high tier services | Where risk matters most |
| 3 | Internal tools and libraries | Bulk, lower urgency |
| 4 | Legacy, archived and odd repos | Decide per repo whether to include |
Wave 2 can come earlier if risk demands it, but only after wave 1 has proven the handoff.
Automate the connection
Hand onboarding does not survive past 50 repos. Look for installation at organization level, with repository selection by label or list, and an API to add repos in bulk. If you pull from GitHub, remember its documented limits: 5,000 requests per hour for authenticated users, with higher caps for some apps, plus secondary limits on concurrency. Space bulk operations accordingly and read the rate limit headers rather than guessing (see Sources).
Verify each wave
For every wave, check:
- Repos with a completed scan, out of repos in the wave.
- Manifests found per repo, compared with a quick file search for lockfiles.
- Scans that failed or returned partial results, with the cause.
- Repos with no owner resolved.
Anything below 100 percent goes on a fix list before the next wave. Use the coverage checklist to decide what counts as complete.
Hand off findings
Do not send the first scan as a raw dump. For each team, prepare:
- Counts by severity and the three items to fix first.
- Which findings are reachable.
- A named contact in the security team.
- The date any gate will start, if one is planned.
Hold a 20 minute office hour during the first week of each wave. Questions raised there improve the next wave's note.
Track the program
| Metric | Reviewed |
|---|---|
| Repos onboarded out of total | Weekly |
| Coverage verified out of onboarded | Weekly |
| Findings opened, closed, overdue | Weekly |
| Repos with unresolved owner | Weekly |
| Teams that asked for help | Per wave |
Common mistakes
- Starting with legacy repos because they have the most risk. They also have the most noise.
- Skipping the denominator, so nobody knows what is missing.
- Turning on gates in the same wave as the first scan.
- Forgetting new repositories created after onboarding. Automate detection of new repos so coverage does not decay.
Safeguard offers asset discovery to find repositories, SBOM and dependency scanning, and a free scan at gold.safeguard.sh/scan to try on a pilot repo.
Try it yourself
Click through it at your own pace, or open it full screen.
Imagine this view for wave one. Which repos would you expect to see, and which would be missing?
Quick check
How big should wave one be?
Twenty to fifty repositories from teams willing to give feedback.
Why keep gates off in early waves?
The first scan reveals existing findings. Blocking on them punishes teams for history before routing and noise are tuned.
Sources
Last reviewed: 19 October 2026.
