Measure it. Capture pull request open to merge time, security check duration, and rerun rate for a few weeks before the tool arrives, then compare after. If the median cycle time rises and the check is the longest step, the tool is slowing you down. Opinions do not settle this; a baseline does.
Capture a baseline first
Before turning on a new check, record for four weeks:
- Median and 90th percentile time from pull request open to merge.
- Duration of each existing CI check.
- Share of pull requests that need a rerun because of a flaky check.
- Share of pull requests that wait on a human for security reasons.
If you already track DORA metrics, you have a head start. DORA defines change lead time as the time from commit to running in production, and change fail rate as the share of deployments needing immediate intervention. A security check that adds ten minutes to every pull request shows up in lead time long before anyone complains.
What to compare after
| Signal | Healthy sign | Warning sign |
|---|---|---|
| Security check duration | Shorter than your slowest existing check | Becomes the longest step |
| Median merge time | Flat or small change | Clear step up after rollout |
| Rerun rate | Unchanged | Rises with scanner timeouts |
| Authors fixing in place | Most findings fixed in the same pull request | Findings deferred or dismissed |
| Change fail rate | Flat or lower | Higher, if people bypass checks |
Look at the 90th percentile, not only the median. Slowness hides in the tail, where a large pull request or a cold cache turns a two minute check into twenty.
Separate tool time from human time
A scan that takes three minutes is rarely the problem. The problem is the comment that needs an hour of investigation. Track both machine duration and the time between a finding appearing and a fix landing. If investigation time dominates, the fix is better context in the finding, not a faster runner.
Fixes that usually help
- Scan only what changed on pull requests, and run full scans on a schedule.
- Cache dependencies and results between runs.
- Run the check in parallel with tests, not after them.
- Set a timeout and decide in advance what happens when it fires.
- Suppress known false positives with a reason, so they stop costing minutes.
Do not read too much into one number
DORA's own guidance treats these as measures of a team's delivery system, and they can move for many reasons. Check what else changed in the same weeks: a release freeze, a new framework, an incident. Use the numbers to start a conversation with the team, not to grade them.
Quick check
What is an acceptable added time for a security check?
There is no universal number. Agree a budget with the teams, such as staying below your slowest existing check, and review it quarterly.
Should security checks run before or alongside tests?
Alongside, when your CI allows it. Running in parallel removes the added wait while still reporting on the same pull request.
Sources
Last reviewed: 19 October 2026.
