Security gates add time to lead time for changes, since a change cannot deploy until the gate finishes. Whether that hurts depends on how long the gate takes, how often it fails and how long failures wait for a fix. Measure the gate's share of lead time instead of assuming.
What DORA means by lead time
DORA's guide to its software delivery metrics defines lead time for changes as the time it takes for a change to go from committed to version control to deployed in production. It sits beside deployment frequency, change fail rate, failed deployment recovery time and deployment rework rate, which together make up its current five metric model.
Because lead time runs from commit to production, everything in between counts, including your security checks, the wait for a reviewer and the time a failed gate sits unfixed.
Where gates add time
- Run time of the scan itself.
- Queue time before the scan starts.
- Time a failed gate waits before someone looks at it.
- Time to fix the finding and re-run.
- Time waiting for an exception decision, if one is needed.
Items 3 to 5 are almost always bigger than item 1. A scan that takes minutes is rarely the problem. A failed gate that waits a day for a decision is.
Steps to measure
- Take a sample of recent changes with their commit time and deploy time.
- For each, record the timestamps of the first security gate start and the final gate pass.
- Subtract to get the gate span, and divide by total lead time to get its share.
- Split changes into those where the gate passed first time and those where it failed at least once.
- Compare the lead time distribution of the two groups.
If first time passes show a small gate share and failed ones show a large one, your lever is failure handling, not scan speed.
What to conclude
| What you see | Likely reading |
|---|---|
| Gate share small for all changes | Gates are not your lead time problem |
| Gate share large only after failures | Improve failure messages, ownership and exceptions |
| Gate share large even on passes | Look at queue time and scan duration |
Do not assume that removing a gate improves outcomes. DORA treats throughput and instability together, and a change that ships faster but fails more often is not progress. Look at change fail rate and recovery time in the same period before drawing conclusions.
Cautions
Lead time distributions are skewed, so compare medians and a high percentile instead of averages. Small samples mislead, so use several weeks of data. Different repositories have different pipelines, so compare each against itself.
Quick check
Should security time be excluded from lead time?
No. DORA's definition runs from commit to deployment. Keep it whole and break it into parts for analysis.
Is a faster gate always better?
A faster gate helps if it keeps its accuracy. A gate that is quick because it checks less is not an improvement.
How Safeguard fits
Safeguard provides policies, gates and dependency scanning so gates can be tuned to block what matters and let the rest through. Try the free scan at gold.safeguard.sh/scan.
Sources
- DORA, DORA's software delivery performance metrics: https://dora.dev/guides/dora-metrics/
Last reviewed: 19 October 2026.
