Three things that go wrong in a spreadsheet
The denominator moved. You committed to 186 findings. Scanning carried on. By the time the team had closed forty, the total read 210, and the chart you showed your CTO in January no longer described anything. The work was going fine. The measurement was not.
Done meant a ticket closed. Somebody moved a card to the right. Nothing checked whether the vulnerability was still there. Six weeks later an assessor asked for proof and the honest answer was that the ticket was closed, which is not the same claim.
Nothing distinguished finished from empty. A repository name with a typo in it matches no findings. The burndown sits at zero from the first day and looks exactly like success. Nobody notices until the quarter ends.
Four decisions, then it runs itself
Pick what you are driving to done. Vulnerabilities, dependencies, or whole repositories. The choice decides which finish criteria and which filters are meaningful, so nothing later offers you an option that cannot apply.
Say what finished means. Gone from a later scan. Moved past the fix version. Package removed. On a supported release. On the latest version. No fixable advisory left. Combine them with all or any.
Choose the set, with the count in front of you. Filter by repository, weakness class, impact threshold, exploitation signal, reachability verdict, internet exposure, supply chain flag, lifecycle or licence. The count updates as you go, so you commit to a number you have seen rather than one you find out later.
Freeze it, or let it grow. A frozen campaign fixes its cohort at creation and nothing joins afterwards. One that allows scope creep admits newly matching items on every evaluation. The first gives you a burndown that can land. The second is honest about a problem still getting worse.
Closed, and closed with proof, are different numbers
When a later scan of the same repository no longer reports a finding, Campaigns closes the item and records which scan run proved it. When something else closes it, the item is still closed, but the run is missing and the campaign says so. Those two counts are never added together.
A campaign where every closure rests on a claim gets told plainly, on its own page, before an assessor is the one who points it out. The fix is not a policy change. It is re-scanning the repositories in scope.
Criteria that work by absence require a scan newer than the moment the item joined the campaign. A repository nobody has re-scanned closes nothing, because reading silence as success is the failure this guards against.
Eleven names, one feature
Nobody agrees what to call this. The term changes between industries, between auditors, and between one security leader and the next. Every one of these is the same machinery with a different scope and a different definition of finished.
AppSec remediation campaign
The general case: a named push across several services at once.
Vulnerability remediation campaign
The older name, usually tied to a quarterly commitment or a customer requirement.
Risk reduction sprint
Short and bounded, aimed at whatever carries the most risk right now.
AppSec debt liquidation
The pile that accumulated faster than anyone cleared it.
Flaw eradication campaign
One weakness class, everywhere it appears, driven to zero.
Exploitation surface reduction
What an attacker could reach and could use, ahead of what merely scores highly.
Security hygiene sprint
Bringing a set of repositories up to a baseline.
Dependency upgrade wave
Moving packages off versions that are unsupported or carry known fixes.
SLA breach remediation
What is already past the window your own policy set.
Audit readiness sprint
Clearing what an assessor will ask about, with the evidence attached.
Policy enforcement wave
Clearing the backlog that would fail a build gate, so the gate can be switched on.
A backlog of 186 is not 186 equal jobs
Vulnetix already holds the things that decide how hard each item will be: single-maintainer files where the review pool is one person, whether a patch exists at all, how far each version has to move against your own autofix ceiling, who can actually merge in the repositories in scope, which contributors are still active, and which suppressions expire mid-campaign. A campaign puts them on the same page as the burndown rather than leaving them to be discovered in the second week.
For the part of the backlog with no patch at all, the campaign lists what can be done instead: detection rules matched to the CVEs involved, ATT&CK mitigations and D3FEND counter-techniques, package firewall entries already blocking the packages, and the quality gate conditions ready to switch on once the backlog is clear.