Divide the number of open vulnerabilities by your net closure rate, which is items closed per week minus new items arriving per week. The answer is a date range, not a promise. If the net rate is zero or negative, the backlog never clears, and the forecast says so.
Why the simple version works
Queueing theory gives the idea. Little's law states that the long-term average number of items in a system equals the average arrival rate multiplied by the average time an item spends in the system. For a backlog, that means size, arrival rate and time to clear are linked, and you can reason about one when you know the other two. See Little's law for vulnerability backlogs for the full idea.
The forecast below is a simpler cousin: it assumes the rates stay steady, and it breaks when they do not.
How to compute it
Step 1: gather four numbers
- Open items now, filtered to what you intend to fix. Exclude items you have formally accepted.
- Closed per week, averaged over the last eight to twelve weeks.
- New per week, averaged over the same period.
- The best and worst week of each, to set the range.
Use the same definition of "item" throughout. If you count findings one way and close tickets another, the forecast is nonsense. A guide to this trap is in percent versus count: the denominator problem.
Step 2: compute with example numbers
These figures are made up to show the arithmetic.
| Measure | Typical | Slow case | Fast case |
|---|---|---|---|
| Open items | 240 | 240 | 240 |
| Closed per week | 30 | 24 | 36 |
| New per week | 18 | 22 | 14 |
| Net closure per week | 12 | 2 | 22 |
| Weeks to clear | 20 | 120 | about 11 |
The typical case clears in 20 weeks. The slow case is 120 weeks, which is a polite way of saying that the problem is inflow. A single number such as "20 weeks" would have hidden that. Show all three columns.
Step 3: look at the inflow
When the slow case is bad, the lever is rarely heroics on closure. Reduce what arrives. Block new vulnerable dependencies at pull request time, retire unused packages, and update on a schedule so advisories do not stack up. These are covered in net vulnerability debt: inflow versus outflow.
Step 4: recheck monthly
A forecast ages quickly. A new critical advisory in a widely used library can add dozens of items in a day. Recompute monthly, and keep the previous forecasts next to the new one. If the clear date keeps moving out, say so to leadership early, with the cause.
Try it yourself
Open the demo and look at how open findings, severity and status are grouped. Think about which of those groups you would count as the backlog in your own forecast, and which you would exclude.
Click through it at your own pace, or open it full screen.
Traps to avoid
- Counting duplicates. One flaw in ten services is ten items but may be one fix.
- Treating all items as equal. Clearing 200 low items does not offset one reachable critical.
- Forgetting new work. Features add dependencies every sprint.
Safeguard's reachability analysis helps narrow the backlog to findings in code that runs, and continuous monitoring keeps the open count current so the forecast does not rely on a stale export.
Quick check
What if the net rate is negative?
The backlog grows. Report that plainly, and focus on cutting inflow or adding capacity, since faster closure alone will not change the trend.
How many weeks of data should I use?
Eight to twelve is a reasonable start. Use more if your rate swings seasonally, and show a range to cover the swings.
Sources
Last reviewed: 19 October 2026.
