Net vulnerability debt is weekly inflow minus weekly outflow. If more findings arrive than you close, the backlog grows even when every team is working hard. Track the three numbers together, by tier, and treat a persistent positive net as a capacity or source problem, not a motivation problem.
Three numbers, one small chart
For each week, and for each priority tier, record:
- Inflow: new findings opened, including reopened ones.
- Outflow: findings closed because they were fixed, mitigated, or removed. Count accepted risk separately.
- Net: inflow minus outflow. Positive means the backlog grew.
Plot net as bars above and below zero, with the open total as a line. This shows momentum, which a single snapshot count cannot.
Why a flat backlog can hide trouble
A stable open count could mean you are in balance. It could also mean a new scanner added a big batch of findings while a clean up removed an equal batch. Inflow and outflow tell the two stories apart.
Spikes in inflow often have a cause you can name: a new scan type, a newly onboarded repository, a widely used library with an advisory. Annotate them on the chart so the next reader does not have to guess.
What drives inflow
Reducing the backlog is partly about reducing what enters it:
- Dependency churn. Older, unmaintained packages generate advisories steadily.
- Base image drift. Images that are rarely rebuilt collect operating system issues.
- New code. Without checks in the pipeline, new problems are introduced as quickly as old ones are fixed.
- Scope growth. Adding assets to the inventory adds findings. That is progress, so label it.
Gating new high risk findings at pull request time is the cheapest way to reduce inflow, because the author still has context.
What drives outflow
- Easy fixes made cheap: automated upgrade proposals reviewed by humans.
- Removal: deleting unused dependencies and services closes more findings than patching them.
- Prioritisation: not spending time on findings in code that cannot be reached, so effort goes to those that can.
- Ownership: findings with an owner close faster than findings without one.
Set a realistic goal
A goal like "net zero for criticals within a quarter" is clear and checkable. A goal like "zero vulnerabilities" is not, and invites the gaming described in Goodhart's law in security metrics.
Safeguard note
Safeguard's policies and gates can stop new high risk dependencies at pull request time, and reachability analysis helps decide which findings deserve the outflow effort. Both are available on the platform today.
A worked example
Suppose a team sees 40 new high severity findings and closes 30 in a week. Net is plus 10. If this repeats for a month, the backlog grows by about 40 items despite the team closing a large number. Pushing the team to work harder may not help. Cutting inflow, by gating new risky dependencies or removing unused packages, might.
This is why the three numbers belong together. Outflow alone makes hard work look like success. Inflow alone looks like failure. Net shows the real direction.
Quick check
Should accepted risk count as outflow?
Show it separately. Counting it as closed makes the net look better than the exposure really is.
What is a healthy net?
Zero or negative for your top tiers, sustained over several weeks.
Last reviewed: 19 October 2026.
