Detection lag is the time from a public advisory to the moment your team has a ticket for it. Measure it with three timestamps: advisory published, first alert, ticket opened. Report the median and the slowest case, then work on whichever gap is larger.
Define the intervals
| Interval | From | To | Who controls it |
|---|---|---|---|
| Source lag | Advisory published | Your tool first shows it | Database and scanner |
| Triage lag | First alert | Ticket opened | Your team |
| Fix lag | Ticket opened | Fix deployed | Your team and the maintainers |
Detection lag is the first two added together. Fix lag is a separate metric, often called time to remediate. Mixing them hides where the delay is.
Collect the timestamps
- Take the publication time from the advisory record. Note that a database may publish later than the original disclosure, so record which source you used.
- Capture the first time your tool surfaced the finding, from its audit log or API.
- Record when a ticket was created, from your tracker.
- Store all three against the advisory ID and the affected service.
For a first pass, a spreadsheet of ten recent advisories is enough. You do not need a dashboard to learn something useful.
Read the results carefully
Median hides the pain. Look at the slowest quarter of cases, and ask what they have in common. Typical patterns:
- Slow source lag on advisories without package mapping. NVD says CVEs outside its priority set may not be scheduled for enrichment, so this is plausible.
- Slow triage lag on alerts sent to a shared inbox.
- Slow triage lag on services without a named owner.
Shrink each interval
For source lag, add a second advisory source and use a stored inventory so a new record is matched immediately. For triage lag, route by tier, name owners and set acknowledgement windows. See tier vulnerability alerts: page, ticket or digest.
Avoid the traps
Do not compare teams by this metric without context, since services differ. Do not set a target before you have measured a baseline. And do not count automatically closed alerts as fast, because they were never real work.
Related: how fast does a new advisory reach your scanner.
Where Safeguard fits
Safeguard's dependency scanning and compliance evidence automation keep timestamps on findings and decisions, which feed this kind of measurement. A free scan is a place to start.
Try it yourself
Click through it at your own pace, or open it full screen.
Follow a finding from detection to a tracked item and note where a timestamp could be recorded.
Quick check
What is a good detection lag?
There is no universal figure. Measure your baseline first, then improve the slowest cases.
Is detection lag the same as time to remediate?
No. Detection lag ends when a ticket exists. Remediation covers the fix and deploy after that.
Sources
Last reviewed: 19 October 2026.
