To reduce a vulnerability backlog, close findings faster than new ones arrive. Prioritizing on its own won't do that. Measure inflow and outflow, then work both sides: stop new findings at the pull request, filter noise before anyone triages, rank what's left by real exploitability, retire what doesn't need fixing, and fix the rest in campaigns your developers can absorb.
This guide explains why backlogs grow, then walks through nine steps to shrink one and keep it small.
What is a vulnerability backlog?
A vulnerability backlog is every open security finding your team has detected but not yet fixed, retired, or formally accepted. It usually spans code (SAST), open-source dependencies (SCA), containers, leaked secrets, cloud misconfigurations, and pentest results, often spread across several tools that each keep their own list.
The backlog is one part of vulnerability management. It's the part where findings go to wait.
Why vulnerability backlogs keep growing
A backlog is a flow. Its size changes by one simple rule:
Backlog change = new findings in − findings closed out
Say your scanners add 400 findings a month and the team closes 300. The backlog grows by 100 a month however carefully you prioritize. Re-sorting the queue changes which findings get fixed, but not how many.
Inflow tends to rise on its own:
- Coverage grows. Every new repository, dependency, container image, and cloud account adds findings.
- Disclosures arrive daily. A new CVE in a library you already use creates findings in code nobody touched.
- Scanners overlap. Two tools reporting the same issue doubles the count without doubling the risk.
Outflow is usually capped by people. Every finding needs someone to confirm it's real, find the owner, write a fix, and get it reviewed. When that work is done one ticket at a time, the backlog grows.
Why reducing the backlog matters
Not every open finding is dangerous, but the backlog hides the ones that are. A critical that's actually exploitable looks the same as fifty that aren't, so it waits in the same queue.
A large backlog also wears down trust. Developers learn that security tickets are mostly noise, security teams spend their week re-sorting lists, and leadership gets the same answer every quarter about why the number hasn't moved.
Regulators now expect risk-based remediation. In June 2026, CISA issued Binding Operational Directive 26-04, which replaced fixed federal patch deadlines with timelines based on four factors: asset exposure, Known Exploited Vulnerabilities (KEV) status, whether exploitation can be automated, and technical impact. The directive covers federal agencies, but the model works for any backlog.
How to reduce a vulnerability backlog in 9 steps
Steps 1–3 cut the inflow and the noise. Steps 4–5 decide what actually needs fixing. Steps 6–9 raise the outflow.
1. Measure the backlog as a flow
Before changing anything, get four numbers for the last 90 days:
- Open count, split by source (code, dependency, container, secret, cloud, pentest).
- Age, bucketed as under 30 days, 30–90 days, 90–365 days, and over a year.
- Inflow: new findings per week.
- Outflow: findings fixed, plus findings retired with a reason, per week.
If inflow is higher than outflow, no prioritization scheme will shrink the backlog. The age buckets tell you where to start: findings over a year old are often in code that has changed or been deleted, and they close quickly once someone checks.
2. Stop new findings at the pull request
The cheapest finding to fix is one that never merges. Scan every pull request, not only the default branch on a schedule, so the author fixes the issue while the code is still fresh in their mind. Then add guardrails so the same class of issue doesn't come back:
- Pin and update base images on a schedule.
- Block known-bad dependency versions in CI.
- Catch hardcoded secrets before they're committed, not after.
Every finding stopped here is one that never enters the backlog.
3. Cut the noise before anyone triages
Much of a typical backlog isn't real risk. In one study across five Nullify production tenants, 57% of 14,847 SAST findings triaged over 90 days were ultimately classified as false positives. Every one of those cost someone time before the real findings could be found.
Filter automatically, and record why each finding was dismissed:
- Deduplicate the same issue reported by more than one scanner.
- Drop unreachable code: dead code, test fixtures, example files, and dependencies that are never called.
- Close findings in deleted or archived repositories.
- Mark benign configurations that a rule flags but that your environment makes safe.
Keeping the reason means a reviewer can audit the decision instead of redoing it.
4. Rank what's left by real risk, not raw severity
CVSS describes how bad a vulnerability class could be in theory. It doesn't know whether the vulnerable function is reachable in your deployment. Layer signals that do:
| Signal | What it tells you | Source |
|---|
| Known exploitation | Attackers are already using it | CISA KEV catalog |
| Exploit likelihood | Probability of exploitation in the next 30 days, updated daily | FIRST EPSS |
| Exposure | Whether the asset is reachable from the internet | Your asset inventory and cloud config |
| Reachability | Whether untrusted input can reach the vulnerable code | Code analysis |
| Business impact | What an attacker gets: customer data, payments, production control | Your service catalog |
| Severity | Theoretical impact of the vulnerability class | CVSS |
A KEV-listed, internet-facing, reachable finding goes to the top. A CVSS 9.8 in an internal service that no untrusted input reaches can wait. Use EPSS to sort the backlog, not to delete from it: a low score is a forecast, not proof of safety.
5. Retire what doesn't need fixing, and say why
Some findings shouldn't be fixed: the system is being decommissioned, a compensating control blocks the path, or the risk is too small to justify the change. Leaving them open inflates the backlog and buries real work.
Close them explicitly instead:
- Record the reason and who approved it.
- Set an expiry date so accepted risks are reviewed, not forgotten.
- Report retired and accepted findings separately from fixed ones, so the backlog shrinks honestly.
The thing to avoid is the silent bulk close. Suppressing old findings to hit a number lowers the count without lowering the risk.
6. Group findings by fix, not by finding
One dependency upgrade can close dozens of findings across many repositories. One helper function rewrite can fix a whole class of injection bugs. If those findings sit as separate tickets, they get worked separately, or not at all.
Group the remaining backlog into campaigns, each with one objective, one owner, and a progress count:
- "Upgrade every service off the vulnerable version of a common library."
- "Remove every leaked secret from source."
- "Eliminate this CWE across the payments services."
Campaigns turn a 2,000-row list into a dozen goals a team can actually finish, and they stop the long tail of forgotten repositories.
7. Route each fix to the code owner and pace the work
The fastest person to fix a vulnerability is the one who owns the code. Route using the commit author first, then CODEOWNERS, then the wider team.
Then pace it. Dropping 200 tickets on a team in one sprint doesn't clear 200 findings. It teaches developers to ignore security tickets. Cap how many open security fixes each repository and each person carries at once, and feed in the next batch as the current one merges.
8. Hand developers fixes, not tickets
A finding that arrives as a pull request with a minimal, root-cause fix merges faster than a ticket that says "this endpoint is vulnerable to SSRF." A good fix:
- Closes the root cause, not just the symptom the scanner flagged.
- Passes the existing build and tests before anyone is asked to review it.
- Explains itself: what was wrong, how it could be exploited, and what changed.
Keep a human approving every merge. Speed that skips review only moves the risk somewhere else.
9. Set SLAs by risk tier, escalate, and report the burn-down
Give each risk tier a target fix time, informed by the same factors as step 4. When a fix stalls, escalate it to the owner and their lead in the channel they actually read, with the risk and deadline stated.
Report the burn-down each week: inflow, outflow, open count by age bucket, and progress per campaign and per team. If inflow is creeping back above outflow, you'll see it in weeks, not quarters.
Common mistakes when reducing a vulnerability backlog
- Prioritizing without adding capacity. A perfectly ranked queue still grows if fixes don't outpace findings.
- Bulk-closing to hit a target. Suppressing old findings makes the chart look good and leaves the risk in place.
- Sorting by CVSS alone. It fills the top of the queue with unreachable findings and lets exploited ones sit lower.
- Flooding developers. Hundreds of tickets at once gets security tickets ignored, not fixed.
- Tracking only the open count. Without inflow and outflow, you can't tell whether the backlog is shrinking or just being re-sorted.
- Ignoring the age of open findings. Old findings drop out of mean-time metrics because they were never fixed. Track their age directly.
Vulnerability backlog reduction checklist
- Inflow, outflow, open count and age buckets are measured weekly.
- Every pull request is scanned before merge.
- Duplicates, unreachable code and test fixtures are filtered automatically, with the reason recorded.
- Ranking uses KEV status, EPSS, exposure, reachability and business impact, not CVSS alone.
- Accepted risks have an approver, a reason and an expiry date, and are reported separately.
- Recurring findings are grouped into campaigns with one owner each.
- Fixes route to the commit author or code owner, with a cap on open fixes per repository.
- Fixes arrive as pull requests that pass the build and tests, and a human approves every merge.
- SLAs exist per risk tier, with automatic escalation.
- The burn-down is reported per campaign and per team.
How Nullify reduces vulnerability backlogs
Nullify puts code, secrets, cloud, dependency and pentest findings into one backlog and scores each finding 0–100 on severity, exploitability, reachability and business impact. Actively exploited vulnerabilities and zero-days affecting your stack move to the top. Unreachable code, test fixtures and benign configurations are filtered out before a person reviews anything.
From there, security leaders run campaigns against a class of findings, scoped by type, CWE, CVE, repository, team or severity. Nullify opens minimal fixes that are validated against your build, routes them to the owner from CODEOWNERS and commit history, and paces the work at no more than 3 open fix PRs per repository and 5 per remediation plan. Stalled PRs are escalated in Slack, your developers approve every merge, and reporting tracks resolved versus remaining for each campaign and team.
One HealthTech team cut its open vulnerabilities from 1,996 to 565 in a quarter, and SmithRx merged 324 patches in a single month. See how campaigns work on the security program management page.
Frequently asked questions
Why does our vulnerability backlog keep growing?
Detection scales with your codebase, but remediation scales with people. Each new repository, dependency and disclosed CVE adds findings, while every fix still needs someone to confirm it, find the owner, write the change and get it reviewed. When new findings arrive faster than fixes merge, the backlog grows whatever the prioritization.
What should we fix first in a vulnerability backlog?
Start with findings that are known to be exploited (on the CISA KEV catalog), reachable from untrusted input, and on internet-facing or business-critical systems. Then work down by exploit likelihood and impact. Severity scores alone aren't enough, because they don't account for whether the vulnerable code runs in your environment.
Is it OK to close old vulnerabilities without fixing them?
Yes, if each closure has a reason, an approver and, for accepted risks, an expiry date. Old findings in deleted code or decommissioned systems should be closed. What isn't OK is bulk-suppressing findings to hit a target, because that lowers the count without lowering the risk.
How long does it take to clear a vulnerability backlog?
It depends on the backlog's size, how much is noise, and how fast fixes merge. Filtering duplicates and unreachable findings often removes a large share in the first weeks. After that, progress comes down to outflow beating inflow, so track the weekly burn-down rather than aiming for zero by a fixed date.
