Roll out in waves: inventory every repository, pilot on three to five, onboard in batches of similar repos in report mode, then turn on blocking per wave once findings are triaged. Measure coverage weekly. Do not flip enforcement on all repos at once.
Step 1: inventory and classify
You cannot onboard what you cannot list. Pull all repositories from your source host, then tag each with owner team, language, deploy status and criticality. Archived and forked repos can usually be set aside. Asset discovery tooling helps if repos live on several hosts.
Step 2: pick a pilot
Choose three to five repos covering your main languages, with friendly owners. The goal is to find template bugs, noisy rules and missing inputs, not to prove the tool works. Expect to change the shared pipeline during this phase.
Step 3: define waves
Group repos so a wave shares tooling and a few owners. Example plan:
| Wave | Repos | Mode | Exit condition |
|---|---|---|---|
| Pilot | 5 | Report | Template stable, noise reviewed |
| 1 | Critical customer facing services | Report then block on critical | Owners triaged open findings |
| 2 | Remaining production services | Report then block on critical | Same |
| 3 | Internal tools and libraries | Report | Coverage above target |
| 4 | Long tail | Automated onboarding PR | Opt out list reviewed |
Step 4: automate the onboarding change
Do not ask 500 teams to edit a file by hand. Open a pull request in each repo that adds the call to the shared workflow, with a message explaining what it does and who to ask. A script plus the host API can create these in bulk. Keep PRs small so owners merge quickly.
Step 5: report mode, then enforce
In report mode developers see findings without blocked merges. After the first triage pass, turn on blocking for new critical findings only. Gating on new code avoids punishing teams for old debt. See quality gates on new code only.
Step 6: measure and communicate
Track repos onboarded, repos with a successful scan in the last seven days, and open findings by age. Share a simple chart per wave. Celebrate teams that clear findings, and follow up quietly with ones that have not merged the onboarding PR.
Try it yourself
The demo walks through building a dependency inventory, which is the first output you will want per repo.
Click through it at your own pace, or open it full screen.
Quick check
How long should report mode last?
Long enough for one triage pass per team, often two to four weeks. Set an end date up front or it becomes permanent.
Should we scan archived repositories?
Usually not, but record the decision. If code is still deployed from an archived repo, scan it.
Safeguard offers asset discovery, SBOM and dependency scanning, and a CLI for bulk pipeline onboarding, and you can start with the free scan at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
