Every organisation that has run scanners for more than a year has the same chart: findings created climbing steadily, findings closed flat. The usual explanation is that engineering does not prioritise security work. That is occasionally true and usually not the real cause.
The real cause is that the programme is generating more obligations than it can possibly discharge, and has no mechanism for deciding which ones matter.
Three fixable causes
Severity is being read off the CVE, not the environment. A critical-rated vulnerability in a library your application never calls, running in a container with no network egress, is not a critical risk to you. Reachability analysis, exploitability data such as EPSS, known-exploited catalogues and asset context routinely reclassify a large share of “critical” findings into something that can wait. Without that context, teams either treat everything as urgent — which they cannot sustain — or quietly treat nothing as urgent.
Nobody owns the finding. A vulnerability assigned to a repository rather than a team is assigned to no one. Service ownership metadata that maps every asset, image and repository to an accountable team is unglamorous groundwork, and it is usually the single highest-leverage change available.
There is no exception path. When the only options are “fix it” and “ignore it”, teams pick ignore, and the finding stays open forever polluting the metrics. A documented risk-acceptance process — with an owner, an expiry date and a review — turns a permanently open ticket into a deliberate, time-boxed decision.
What a workable model looks like
Define severity from environmental risk, not from the scanner. Combine the base severity with exploitability, reachability, asset criticality and exposure. Publish the formula so nobody has to argue about a rating case by case.
Set SLAs per severity and enforce them at the tier that matters. Critical internet-facing issues in days; high in weeks; medium and low into the normal backlog with a periodic sweep rather than an individual deadline.
Stop the bleeding before draining the pool. Gate new findings at the pull request — where the cost to fix is minutes — and baseline the existing debt so the pipeline is not failing on issues nobody introduced this week. A programme that prevents new debt while chipping at the old is the only version that converges.
Report on the right things. Open-finding count measures scanner coverage, not risk. Track mean time to remediate by severity, the age profile of open critical findings, the percentage of assets with a named owner, and recurrence rate by defect class. Those tell you whether the programme is working; a raw count does not.
The measure that matters
The useful question is not “how many findings are open?” but “how long does a genuinely exploitable, internet-facing issue survive in our environment?” If that number is trending down, the programme is working — even if the total backlog is not shrinking. If it is not, no amount of backlog reduction elsewhere is buying you safety.