Roll a security tool out in waves: one friendly team first, then volunteers, then the majority, then holdouts. Run in report only mode at the start, fix noise and speed problems with the first team, and turn on blocking last. A tool that surprises people on day one gets disabled by week two.
Wave 0: one team, report only
Pick a team that ships often and will give honest feedback. Install the tool, let it scan, and block nothing. Your goals are to find noise, measure scan time, and learn which findings people actually fix.
Write down the false positives and the slow steps. Those become your tuning list before anyone else sees the tool.
Wave 1: volunteers
Open the door to teams that ask. Use a short setup guide written from wave 0, and a named contact who answers in hours, not days. Volunteers tell their peers whether the tool is helpful or a chore, and that word of mouth is worth more than a mandate.
Wave 2: the majority
Move to scheduled onboarding, a few teams at a time, with a published date. By now:
- Scan time is under your agreed budget.
- The top false positive patterns are suppressed with documented reasons.
- Findings have owners (see routing by code ownership).
- A dispute path exists.
Keep the tool in report only mode for two weeks per team before any gate is switched on.
Wave 3: holdouts and exceptions
Some teams will have reasons: an unusual build, a legacy language, a regulated environment. Listen first. Offer a time limited exception with an end date and an owner. A permanent exception list is a sign the tool does not fit, and that is useful information.
The switch from report to block
| Stage | Behavior | Exit criterion |
|---|---|---|
| Observe | Results visible, nothing blocks | Noise list worked through |
| Warn | Check shows as advisory on pull requests | Authors fix most warnings |
| Block | Only the highest priority findings fail the check | Dispute path tested |
Announce each switch a week ahead, with the date and the rule. Do not add new rules and a new block in the same week.
Measure the rollout, not just the tool
Track the share of repos scanned, median scan time, share of findings fixed within the agreed window, and the number of disputes. Rising disputes with falling fixes mean the rules are wrong for that team.
Try it yourself
Click through it at your own pace, or open it full screen. Watch how results update over time without anyone running a scan by hand.
Safeguard policies, gates and guardrails can start as advisory and be tightened later. You can try a free scan before involving any team.
Quick check
How long should wave 0 last?
Long enough to see a few weeks of real pull requests, so the noise and timing data reflects normal work and not a quiet week.
Should the first wave be the most security minded team?
Pick a team that gives candid feedback and ships often. A team that loves security tools may forgive problems the rest of engineering will not.
Last reviewed: 19 October 2026.
