To tell whether a vulnerability backlog is really shrinking, chart new findings and closed findings per period side by side, then show the net change. A flat total can hide a team running hard to stand still, and a falling total can hide a scanner that stopped finding things.
The two lines that matter
Inflow is the number of findings that appeared in the period: new advisories against dependencies you already use, new code, new assets coming into scope. Outflow is the number that closed because they were fixed, mitigated or properly accepted.
If outflow exceeds inflow, the backlog is shrinking. If they match, the backlog is stable. If inflow exceeds outflow, it grows even if everyone is busy. This is more actionable than a burn down line alone because it tells you which side to work on.
Why a burn down is not enough
A burn down chart only shows the remaining total. It cannot say whether progress came from fixes or from something else. Several things shrink a total without reducing risk:
- A scanner configuration change that skips a path
- Closing findings as won't fix without review
- Deleting an archived project from scope
- Duplicate merging after a tool change
Inflow and outflow, with a reason code for closures, makes those visible.
Steps to build it
- Pick a period: weekly for engineers, monthly for leaders.
- Count findings whose first seen date falls in the period. That is inflow.
- Count findings that closed in the period, split by reason: fixed, mitigated, accepted, false positive, out of scope.
- Chart inflow and the fixed plus mitigated part of outflow as paired bars. Show the other closure reasons in a separate color.
- Add a line for the open total.
- Annotate any scope or scanner change on the date it happened.
| Pattern | Likely meaning | Question to ask |
|---|---|---|
| Inflow high, outflow low | Capacity or ownership gap | Who owns the new items? |
| Outflow high, mostly accepted | Risk being deferred | Are exceptions reviewed? |
| Both low | Scanning coverage may have dropped | Did a scan source stop? |
| Outflow rises after automation | Fix pull requests landing | Are they merged and deployed? |
What leaders should take from it
A leader needs one conclusion: the backlog is shrinking, stable or growing, and why. Use the table pattern names in plain language, add the single biggest driver, and state the action requested, if any. Avoid quoting benchmark rates from other organizations unless you can cite the source.
If the backlog is large, you may need a triage approach as well. See prioritizing a very large finding backlog.
Safeguard's SBOM and dependency scanning can supply the data that feeds both series, and reachability analysis helps separate inflow that matters now from the rest. The free scan gives a starting snapshot.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch how new findings arrive over time even when nothing in your code changed.
Quick check
Why would new findings appear when nobody changed the code?
Because advisories are published after you ship. A dependency you already use can gain a vulnerability record at any time, which counts as inflow.
Is a growing backlog always bad?
Not if scope expanded on purpose, for example onboarding more repositories. Annotate the change so the growth is explained rather than alarming.
Last reviewed: 19 October 2026.
