Fictional example: three vulnerabilities take two, four, and nine days to remediate. Their completed-only MTTR is (2 + 4 + 9) / 3 = five days. Atlassian’s vulnerability metrics use discovery and completed remediation as the endpoints. Its incident metric also uses the acronym MTTR, but means time to resolve a failure. Check the expansion and endpoints before comparing dashboards.
A fourth vulnerability remains open twenty days after discovery. Its final remediation duration is unknown, so it is absent from this completed-only mean. Report its open age and status separately. The diagram below shows these fictional records; it does not describe the performance of a team or security product.
In episode 68 at 11:26, Dan Lorenc argues that defenders need to find and fix vulnerabilities before attackers exploit them. He describes pushing remediation timing negative. Read that as a goal of fixing flaws before a reference event such as public disclosure; elapsed time from discovery to remediation cannot be negative.
This differs from time to exploit, which measures exploitation relative to a stated reference date. A useful remediation report states the vulnerability set, severity, discovery rule, and what counts as a completed fix. Track unresolved vulnerabilities alongside the mean: a falling average among completed fixes can conceal an aging backlog.
Hear it from the guest
“How many of these can we patch or remediate and get to as much of the industry as possible before they do become exploited.”
Quotes lightly edited to remove filler words.
Sources
- Atlassian Compass: Available predefined metrics — Defines vulnerability remediation from discovery to remediation, separately from incident time to resolve; its own metric averages the last ten vulnerabilities.
- Episode 68: Dan Lorenc on fixing vulnerabilities before exploitation — Lorenc's call for negative remediation timing is an operational argument, not a negative elapsed duration under the definition above.
