To tell whether you are closing vulnerabilities faster than you find them, chart findings opened and findings closed per week, then plot the net difference. A net figure above zero for several weeks means the backlog is growing, even if your total count looks stable because of scanner changes.
What the chart shows that a total does not
A single open count mixes two different things: how fast new findings arrive and how fast your team removes them. A flat total can mean both are low, or both are high. These situations need different responses.
Arrival rate is driven by new code, new dependencies, new advisories and scanner coverage. Closure rate is driven by capacity, prioritisation and how easy fixes are.
How to build it
- Choose a period, usually one week.
- Count findings first seen in that period (opened).
- Count findings that reached a closed state: fixed, or removed because the component was removed. Count accepted and false positive separately.
- Subtract: opened minus closed is the net change.
- Plot opened and closed as two lines, with net as bars.
| Pattern | Likely meaning | Response |
|---|---|---|
| Opened above closed, steady | Capacity gap or noisy intake | Prioritise by reachability, fix groups of findings together |
| Opened spikes, closed follows | Healthy surge response | Watch time to close |
| Both low | Little scanning or little change | Check coverage |
| Closed above opened | Backlog shrinking | Confirm closes are genuine |
Traps
Count closed carefully. If "accepted" and "false positive" count as closed, the line can look healthy while real exposure grows. Report those categories separately.
A scanner update that adds a new rule set creates an artificial spike in opened findings. Annotate the chart when scanner coverage changes, so nobody reads a tooling event as a team failure.
Split by severity. A hundred closed low findings do not offset one new critical one.
Use it to ask better questions
If opened beats closed, ask whether the intake is mostly unreachable findings. Reachability analysis can tell you which findings are in code paths your application actually calls, which changes both numbers.
Try it yourself
Open the demo and watch how monitoring surfaces new findings over time. Think about what your weekly opened count would be.
Click through it at your own pace, or open it full screen.
Safeguard offers SBOM and dependency scanning plus reachability analysis, and you can run a free scan at gold.safeguard.sh/scan.
Quick check
Should accepted findings count as closed?
Report them separately. Counting them as closed hides open exposure.
Why did opened findings spike after a scanner update?
New rules or data usually reveal existing issues. Annotate the chart so the spike is not misread.
Last reviewed: 19 October 2026.
