Roll out a new security tool in three stages: report only on one team in the first month, tuned and trusted in the second, and gated and expanded in the third. Turning on blocking everywhere on day one is the fastest way to make developers dislike the tool.
Days 1 to 30: connect and observe
- Name an owner and a backup, plus an engineering champion on the first team.
- Connect the pilot team's repositories and run scans in report only mode.
- Do not open tickets automatically yet. Review the first results as a group.
- Fix the obvious setup issues: unresolved dependencies, wrong build commands, noisy folders such as test fixtures.
- Record a baseline: open findings by severity, scan time, and how many findings are in code that is deployed.
The goal is to make results believable before anyone is asked to act on them.
Days 31 to 60: tune and build trust
- Review the top finding types. For each, decide to fix, suppress with a reason, or adjust a rule.
- Set suppression rules with an owner and an expiry date.
- Turn on pull request comments, still non blocking.
- Ask the first team for feedback every two weeks. Track how many comments they dismiss and why.
- Agree service levels for fixing, such as how fast a reachable critical should be handled. Write them down in a short policy.
Aim for developer trust. If developers dismiss most comments, the problem is tuning, not discipline.
Days 61 to 90: gate and expand
- Add a blocking gate for a narrow, high confidence class first, such as a known exploited vulnerability that is reachable, or a committed secret.
- Provide a clear override path with a reason and an approver, so the gate is a speed bump and not a wall.
- Bring in the next two teams using the first team's tuned configuration as a template.
- Set up a weekly report for engineering leads: new findings, fixed findings, time to fix, and open overrides.
- Review the original success criteria from the pilot and see which are met.
See pull request gate design for what developers notice most.
What to measure at each stage
- Observe: scan coverage, scan time, setup errors.
- Tune: share of findings suppressed with reasons, developer feedback.
- Gate: overrides per month, time to fix, blocked merges later confirmed useful.
Avoid counting raw findings as a success measure. The number often rises early because you are finally looking.
Common mistakes
- Starting everywhere at once, so nobody owns tuning
- Letting suppressions live forever
- Never reviewing overrides
- Skipping the decision record, so six months later nobody knows why a rule exists
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how findings are grouped and prioritized, and think about which view your champion team would want first.
Quick check
When should auto created tickets start?
After tuning, when most findings in the queue are ones you would be willing to fix. Before that, tickets create noise and resentment.
Who owns the tool after rollout?
One named team, usually application security or platform engineering, with a regular review of rules, suppressions and overrides.
Last reviewed: 19 October 2026.
