Home / Knowledge hub / Vulnerability backlog
Knowledge hub
Vulnerability backlog
The growing list of known flaws a team has yet to fix.
What it means
A vulnerability backlog is the list of known security flaws that are open: found, recorded, and not yet fixed or formally accepted. It builds up from scans, tests, bug reports and dependency alerts, and it grows whenever finding outpaces fixing.
A backlog is not a sign of failure in itself. Every software team has one. What matters is whether it is understood: who owns each item, how old it is, how serious it really is, and whether anyone has decided to leave it.
Why it matters
Size hides the dangerous items. When a list holds 4,000 entries, the three that are actually being exploited look the same as 3,997 that are not. Teams then work from the top of a sorted list, or give up, and real exposure stays open.
It also becomes evidence. An auditor, insurer or customer who sees old critical findings with no owner draws the obvious conclusion. A shorter list with clear decisions on each entry says far more about your security than a long one that nobody trusts.
How it shows up
The backlog grows when tools report duplicates, when low-confidence results are never checked, when ownership is unclear, and when security tickets compete with feature work and lose. See finding deduplication and false positives for the noise that inflates it. A single weak library can appear once per project, once per scanner and once per version.
Shrink it by deciding rather than fixing everything. Close what is not real, merge repeats, rank by exploitation and exposure, give each item an owner and a date, and record formal acceptance for what you will not fix (see risk acceptance). Track how long items stay open, report it to leadership each month, and set remediation targets by severity so the numbers drive a conversation.
Questions people ask
Vulnerability backlog, answered
How big should a backlog be?
There is no standard number. A better question is how many items are serious, reachable and unowned.
A hundred reviewed items beat a thousand unreviewed ones.
Should we aim for zero?
Zero open findings is rarely realistic and can push teams to close tickets without fixing anything. Aim for no overdue serious items and a recorded decision on the rest.
Honesty matters more than the number.
Why does it keep growing?
Scanners and dependency alerts add findings faster than a team can fix them, and old items are seldom closed. New code adds more.
Automatic triage and deduplication slow the growth.
Who should own it?
The team that owns the code or system, with security helping to rank. A central security team that owns every ticket becomes the bottleneck.
Each item needs one named owner.
Can we close findings in bulk?
Only with a reason you can show, such as the component is not deployed or the finding was a duplicate. Closing because the list is too long hides the risk.
Keep the reason on record.
Related
Terms that sit next to this one
Vulnerability management
The loop of finding, prioritising, fixing and checking the fix held.
Vulnerability ageing
How long known findings have sat open, as a measure of fix speed.
Finding triage
Sorting new findings into fix now, fix later, duplicate or not real.
Risk-based prioritisation
Ordering fixes by real-world risk, not just by the raw severity score.
Mean time to remediate
The average time from finding a vulnerability to fixing it.
Which items are actually real?
Our findings are exploited before they are reported, so what reaches your list has proof attached and less of it is noise. Severity and confidence are kept apart. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.