Pick three services, pull the last handful of security fixes for each, record five timestamps per fix, and compute the gaps. In about an hour you will know which stage, from alert to deploy, takes longest in your team. It will be rough, and it will still beat guessing.
Before you begin
You need read access to your alerts, repositories and deploy history. You do not need a new tool. A spreadsheet is enough. If you have no recent fixes, use the open alerts instead and record how long they have waited.
The plan, in order
Minutes 0 to 10: choose the scope. Pick three services that differ: one customer facing, one internal, one older. Pick up to five recent security fixes each.
Minutes 10 to 30: collect timestamps. For each fix, record:
- Advisory published (from the advisory record).
- Alert raised in your tooling.
- Fix PR opened.
- Fix merged.
- Running in production.
Gather these from alert pages, PR history and deploy logs. When a timestamp is not available, write "unknown" and note why. Unknowns are findings.
Minutes 30 to 45: compute gaps. Four gaps per fix: advisory to alert, alert to PR, PR to merge, merge to production. Use the median per stage, not the mean.
Minutes 45 to 60: read the result.
| Longest stage | First thing to check |
|---|---|
| Advisory to alert | Alerts enabled, branches scanned |
| Alert to PR | Bot settings, schedules, no-PR alerts |
| PR to merge | Review capacity, flaky tests |
| Merge to production | Approvals, release train, rebuilds |
| Unknown timestamps | Start capturing them |
What a baseline does for you
It gives you a starting point you can defend. When someone asks if you are getting better, you can answer with a number from your own history. It also picks your first improvement for you: the longest stage.
Add the other half
Open the inventory. If you cannot tell which services run a given package, your first improvement is not a stage at all, it is inventory. Generate a software bill of materials per service and keep it current.
Keep the rules simple
- Same definitions for every fix. Decide where the clock starts and stops and write it down.
- Median and a high percentile, not a mean.
- Note the date range you sampled.
- Repeat in a quarter with the same scope so the comparison is fair.
Common surprises
Teams often find that the fix itself was quick, and the waiting happened before and after it. Another frequent finding is that a fix was merged but never deployed to one environment. Both are cheap to correct once visible.
Try it yourself
Open the SCA demo to see an inventory of dependencies, the foundation for any baseline.
Click through it at your own pace, or open it full screen.
Safeguard provides dependency scanning and SBOM generation, and you can run a free scan at gold.safeguard.sh/scan to see current findings for a project.
Quick check
Is a spreadsheet enough?
Yes, for a first baseline. Automate collection once you know which stage matters.
What if I cannot find the timestamps?
Record unknown, and start capturing them for new fixes. That is a useful result.
Last reviewed: 19 October 2026.
