Export the opened and closed dates for serious vulnerability tickets from the last six to twelve months, calculate how many days each took, and show the median, the slowest items and why they were slow. A measured record is more credible than a policy that states a target.
Targets versus measurements
Many policies say "critical vulnerabilities are fixed within seven days". A buyer asks, "show me". If the tickets say otherwise, the policy becomes a liability. If they agree, the policy gains weight.
For a reference point on how a regulator sets timelines, CISA's directive on known exploited vulnerabilities gives federal agencies a default of two weeks for catalog entries with a CVE assigned in 2021 or later, and six months for earlier ones, adjustable in grave risk cases. That binds federal agencies, not you, but it shows that timelines can be tied to evidence of exploitation instead of a flat severity label.
What to export
| Field | Source |
|---|---|
| Finding ID and component | Scanner or ticket |
| Severity and exploitation status | Scanner plus catalog check |
| Detected date | Scanner first seen |
| Ticket opened | Tracker |
| Fixed or mitigated date | Tracker or release record |
| Release that shipped the fix | Release notes |
Note that the clock should start at detection, not at ticket creation, or you will flatter the numbers.
Steps
- Choose the window and the severity cutoff, for example high and critical, and say so.
- Export all matching items, including those still open.
- Calculate days from detection to fix for closed items. For open ones, days so far.
- Report the count, median and the longest few. Skip the average if outliers distort it.
- Add one sentence for each slow item: blocked by upstream, fix needed a major upgrade, risk accepted.
- Compare the result to your stated policy and update the policy if it is unrealistic.
Handling outliers
Every list has some. A slow fix with a documented reason, such as no patched version existing yet and a mitigation applied, is fine. A slow fix with no explanation looks like neglect. Also separate "fixed" from "mitigated" so you do not claim more than you did.
If you lack history
A young company may have just a few items. Show them all. A table of eight honest rows beats a chart built from a thin dataset. Say that measurement began on a given date and what you do going forward.
Make future measurement automatic
Record detected date in the scanner, link tickets to findings, and generate the report from the tracker each month. Then the diligence version is one export, not an archaeology project.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how a finding moves from detection to an available fix, and which steps take time.
Safeguard can open fix pull requests for findings. It is off by default, with every category set to Manual, so your team stays in control of what merges. A free scan shows findings for one repository.
Quick check
Should the clock start at detection or disclosure?
Start at your detection, and also note the public disclosure date when it differs, so the reader sees both.
What if our fix times are poor?
Show them anyway with a plan and a dated improvement. Hiding them is worse.
Sources
Last reviewed: 19 October 2026.
