Remediation time usually goes to waiting, not fixing. Split the path into stages, which are triage, assignment, fix, review, merge and deploy, then measure each. The slowest stage is often triage or deployment, and knowing which one tells you where to spend effort.
Why one number hides the problem
If you only track time from discovery to closure, a slow quarter gives you no guidance. Was the team slow to look, slow to fix, or slow to ship? Each answer needs a different remedy.
The stages
| Stage | Starts when | Ends when | Typical delay |
|---|---|---|---|
| Triage | Finding appears | Severity and relevance decided | Nobody owns the queue |
| Assignment | Triage done | An owner accepts it | Unclear ownership |
| Fix | Owner starts | Change is ready | Complex upgrades |
| Review | Pull request opened | Approved | Reviewer availability |
| Merge | Approved | In main branch | Merge queues, freezes |
| Deploy | Merged | Running in production | Release cadence |
| Verify | Deployed | Rescan shows closed | Delay in rescans |
How to capture it
- Ensure every finding has event timestamps: created, triaged, assigned, pull request opened, merged, deployed, verified.
- Take timestamps from systems, such as the issue tracker, source control and the deploy pipeline, instead of asking people.
- Compute the median and the 90th percentile of each stage.
- Stack the medians in one bar per month, so a shift in the dominant stage is visible.
Reading the result
If triage dominates, assign a daily rotation or auto route by repository ownership. If assignment dominates, you have an ownership gap, so fix the asset to owner mapping. If review dominates, set review expectations for security pull requests. If deploy dominates, the real constraint is your release process, and no scanner will fix that.
Automated fix pull requests shorten the fix stage but not the review and deploy stages. Count them honestly: a bot that opens a pull request nobody reviews has not moved the total.
Cautions
- Stages overlap in practice, so define handoffs clearly.
- Reopened findings should keep their original start time.
- Small samples produce unstable percentiles. Show counts.
Try it yourself
Open the demo and watch how a finding changes as it is monitored. Think about which stage each state corresponds to.
Click through it at your own pace, or open it full screen.
Safeguard provides continuous scanning and fix PRs (off by default, every category on Manual), and you can run a free scan at gold.safeguard.sh/scan.
Quick check
Which stage is usually slowest?
It varies. Triage, assignment and deploy are common, which is why you measure each.
Do automated fix PRs fix the whole timeline?
They shorten the fix stage. Review, merge and deploy still need time.
Last reviewed: 19 October 2026.
