The remediation clock can start at advisory publication, first detection in your environment, or ticket creation. Each gives a different number for the same fix. Choose one start event per metric, label it in the title, and keep the other timestamps so you can answer the other question too.
Three start events
| Start event | Measures | Who controls it |
|---|---|---|
| Advisory published | Total exposure window from public knowledge | Nobody inside your company |
| First detected in your estate | How long you knew and did not fix | Your scanning cadence and coverage |
| Ticket created | Engineering response time | Triage process |
Using publication as the start punishes teams for delays caused by a slow scanner. Using ticket creation hides the time spent before anyone noticed. Using first detection is the fairest measure of remediation work, but it flatters a team whose scanning is infrequent.
Keep all four timestamps
Store at minimum: published time, first detected time, triaged or ticket time, and resolved time. With all four you can report any interval later without redoing data collection. Publication times in the OSV format are UTC, written as RFC3339 timestamps, which is a good convention to use internally as well.
Intervals worth deriving:
- Published to detected: your detection delay.
- Detected to triaged: your triage delay.
- Triaged to resolved: your engineering fix time.
- Published to resolved: the full exposure window.
Splitting the total into these pieces shows where time goes. A long first interval is a coverage problem. A long second one is a process problem. A long third one is a capacity or complexity problem.
The re-detection trap
If a finding reopens, does the clock restart? Decide in advance. A common rule is to keep the original first detected time and add the reopen as an event, so the history is honest. Restarting makes recurring problems look new.
Open items need handling too
Findings that are still open have no resolved time. Excluding them makes the average look better than reality, because the slowest items are exactly the ones that are missing. Report open items by age beside the resolved ones, for example a count over each age threshold.
Write the definition down
A metric card should say: start event, end event, unit of time, treatment of reopened items, treatment of open items, and exclusions. One paragraph is enough. Without it, two people will compute two numbers and both will believe theirs.
Safeguard does this kind of counting in one place: SBOM and dependency scanning, asset discovery and reachability analysis feed the same inventory, so each number can be traced back to its source. Records keep the detection, triage and resolution events, which is what lets each interval be computed later. You can try a free scan at gold.safeguard.sh/scan.
Quick check
Which start event is the standard one?
There is no single standard. Pick the one that fits the decision and label it. Many teams track both published to resolved and detected to resolved.
Should reopened findings restart the clock?
It is usually clearer to keep the original detection time and log the reopen as an event.
Sources
Last reviewed: 19 October 2026.
