To tell whether your vulnerability backlog is growing, chart findings opened and findings closed each week or month on the same axis. If opened stays above closed, the backlog grows no matter how busy the team is. The gap between the two lines is the number executives can act on.
Why the total count alone misleads
A backlog total of 4,000 tells you little. It might be shrinking from 6,000 or growing from 2,000. The total is a stock. Inflow and outflow are flows, and flows explain the stock.
There is a second trap. A new scanner or a new set of repositories adds inflow that is not new risk, it is newly visible risk. Without a note on the chart, a spike reads as a bad month.
The three numbers
- Opened: new findings that appeared in the period. Include new CVEs affecting software you already run, and new software you started scanning.
- Closed: findings fixed, with the fix verified. Do not count findings suppressed or marked not applicable here.
- Dismissed: findings closed as not affected, accepted risk, or false positive. Track these separately.
Keeping dismissed apart matters. If the backlog is falling only because findings are being dismissed, the trend flatters you. A rising dismissed line deserves a review of the reasons.
A worked example, with made up numbers
| Week | Opened | Closed | Net |
|---|---|---|---|
| 1 | 40 | 25 | +15 |
| 2 | 35 | 30 | +5 |
| 3 | 20 | 38 | -18 |
| 4 | 30 | 28 | -2 |
These figures are an illustration only. The point is the Net column. The team looks busy every week, yet the backlog moved by a handful. When the Net column stays positive for a quarter, that is the case for more capacity, fewer inflow sources, or a different prioritization rule.
What changes inflow
Inflow is not fixed. You can lower it with decisions made upstream:
- Block new high risk dependencies at pull request time, so they never enter the backlog.
- Update shared base images and templates, since one change closes many findings at once.
- Retire unused services and packages. A finding on deleted code closes without any fix.
- Use reachability to deprioritize findings in code paths your software never calls, and label them as such rather than hiding them.
What changes outflow
Outflow rises when fixes are cheap to apply. Grouping updates, automating routine version bumps, and giving each finding a named owner usually matter more than asking people to work harder.
How to present it
One chart with two lines and a shaded gap. Add a single sentence: "Net backlog change this quarter: plus 38." If a method change happened, mark it with a vertical line and a label.
Where Safeguard fits
Safeguard can help with the inputs behind this. It runs SBOM and dependency scanning, reachability analysis to separate reachable findings from the rest, and policies and gates that you set. You can try a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Look for findings with a fix available now. Those are the quickest way to raise outflow.
Quick check
Should dismissed findings count as closed?
Report them separately. Mixing them hides whether the backlog shrank because of fixes or because of decisions to stop tracking.
How often should I chart this?
Weekly for the team, monthly or quarterly for executives. The shape should match the audience, but both views come from the same data.
Last reviewed: 19 October 2026.
