Measure it as change lead time for security fixes: the time from the fix being committed to it running in production. Record it per fix, split by release line, and watch the slowest cases rather than the average. A fix that is merged but not deployed protects nobody.
What the metric is
The DORA research program defines change lead time as the amount of time it takes for a change to go from committed to version control to deployed in production. It lists it as one of its software delivery throughput measures. For security work, applying it to fixes only gives you a sharp view of how fast you really close exposure after the code is ready.
This is different from the time to discover or the time to triage. Those come before the fix exists. This one starts when a fix does.
What to record per fix
| Field | Why |
|---|---|
| Fix commit time | Start of the clock |
| First deployed time per environment | Where it waits |
| Time running on all instances | The real finish |
| Release line | Old lines often lag |
| Reason for any wait | Approval, freeze, tests, batching |
Steps
- Tag every security fix in your tracker or commit message so you can pull them later.
- Record the commit time automatically from version control.
- Record deployment time from your deploy system, not from a person typing it in.
- Define the finish as running everywhere, using the check from the post on confirming a fix in production.
- Report the median and the slowest few. Averages hide the stuck ones.
- For each slow fix, write down what it waited for.
- Review monthly and change one thing at a time: a faster approval, a smaller batch, a better test.
What the numbers usually reveal
Waiting time dominates. A fix that took ten minutes to write may wait days for a release train, for approval or for a window. Those waits are choices, and some can be removed. For example, a policy that lets small, tested, security labeled changes use a faster path shortens the wait without removing review.
Pitfalls
- Stopping the clock at merge instead of at production.
- Counting only the newest release line and ignoring backports.
- Using one blended number for urgent and routine fixes.
- Optimizing the metric by shipping untested changes. Pair it with a failure measure.
DORA also lists measures of instability, such as the share of deployments that need immediate intervention and the time to recover from a failed deployment. Watch those next to lead time. Faster is only an improvement when it does not break more.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how findings move from open to closed, which gives you the dates the metric needs.
Safeguard tracks findings through to remediation across your inventory, which helps you see how long vulnerable components stay in production. A free scan is at gold.safeguard.sh/scan.
Quick check
When does the clock start?
When the fix is committed. Discovery and triage time is a separate measure.
When does the clock stop?
When the fix is running on all instances in production, not when it is merged or tagged.
Sources
Last reviewed: 19 October 2026.
