Start with two or three repositories: one that matters to the business, one owned by a team that wants to help, and one ordinary service in between. Scan them, tune the results, then widen in waves. Rolling out to every repository on day one buries teams in findings and burns goodwill.
Why not scan everything at once
A first scan of an older repository can return hundreds of findings. Multiply that by fifty repositories and nobody can tell which results matter. Developers learn that the tool is noisy before it has had a chance to prove itself. A small first wave lets you tune rules, find integration problems and collect a real success story.
Score the candidates
List your repositories and score each from one to three on a few questions.
| Question | Why it matters |
|---|---|
| Is it internet facing or handling sensitive data? | Higher impact if something is wrong |
| Does it deploy often? | Fast feedback on the workflow |
| Is the owning team willing and responsive? | Early feedback is only useful if someone reads it |
| Is the build already healthy, with tests and CI? | Avoid blaming the scanner for a broken pipeline |
| Does it use a common stack? | Findings and fixes carry over to other repositories |
Pick the highest scorers, but make sure at least one is a team that says yes happily.
Build the first wave
- Choose three repositories. One high impact, one friendly, one typical.
- Run in report mode. Do not block anything for the first two weeks.
- Triage together. Sit with the owning team and mark each finding as real, not real or not sure. The ratio tells you how much tuning is needed.
- Tune before widening. Remove rules that are mostly wrong, and set severity thresholds the team agrees with.
- Turn on a narrow gate. Block only new secrets and new reachable critical findings.
- Write down what you learned. Setup time, fix time, complaints, surprises.
Widen in waves
Each later wave can be larger because the setup is documented. A sensible order is to follow business risk: customer facing services next, then internal tools, then archived or low change repositories last. For repositories that rarely change, an inventory plus a periodic scan may be enough.
Signs you are moving too fast
- Developers disable the check in their own workflow files
- The first wave still has unexplained findings nobody has read
- Support questions pile up in chat with no answers
- Pull requests wait on the scan longer than on tests
If you see these, pause the rollout and fix the process.
Try it yourself
Open the dependency inventory demo and look at how the components of one project are listed. Notice how much of the code is third party, which is why dependency scanning is a sensible first step.
Click through it at your own pace, or open it full screen.
Quick check
Should the first repository be the riskiest one?
Not only. A risky repository with a hostile team gives you bad feedback. Pair it with a willing team so you learn from both.
How long should the first wave run before widening?
Long enough to tune and to see one full release cycle, often two to four weeks. Widen when the findings are mostly real and the team asks for fewer surprises, not more.
Safeguard offers asset discovery and SBOM and dependency scanning, which helps list the repositories and components to prioritise. You can start with a free scan of a single repository.
Last reviewed: 19 October 2026.
