Whatever you call it, this is how it gets run
The vocabulary changes between industries, between auditors, and between one security leader and the next. Below is the same feature described eleven ways, with the setup each one implies.
AppSec remediation campaign
A named push against a backlog somebody has committed to clearing, usually across several services at once. Scope by repository and scanner category; done when the finding is gone from a later scan.
Vulnerability remediation campaign
The same work under the older name, often driven by a quarterly commitment or a customer requirement. Freeze the cohort so the number you reported at the start is the number you burn down against.
Risk reduction sprint
A short, bounded push at whatever carries the most risk right now. Scope by impact threshold and exploitation signal, then take the deadline from your remediation policy.
AppSec debt liquidation
Old findings nobody has looked at in months. Scope by age and confidence, exclude test code and suppressed findings, and leave the scope frozen so the pile cannot grow while you work it.
Flaw eradication campaign
One weakness class, everywhere it appears, driven to zero. Scope by CWE, matched exactly, so a campaign against CWE-79 never quietly picks up CWE-790.
Exploitation surface reduction
The findings an attacker could reach and could use. Scope by KEV listing, observed exploitation, reachability verdict and internet exposure, in any combination.
Security hygiene sprint
Bringing a set of repositories up to a baseline rather than chasing individual findings. A repository target covers both the vulnerabilities in it and the dependencies it ships.
Dependency upgrade wave
Moving a package, or a class of packages, off versions that are unsupported or carry known fixes. Done when the package is removed, reaches the latest version, or has no fixable advisory left.
SLA breach remediation
Findings already past the window your own policy set. Every closure is timed against your remediation policy windows and their grace allowances, per severity band.
Audit readiness sprint
Clearing what an assessor will ask about, and being able to show the work. Closures record the scan run that observed them, reported separately from closures without one.
Policy enforcement wave
Clearing the backlog that would fail a build gate, so the gate can be switched to blocking without stopping every pipeline on day one.
Three ways a remediation push goes wrong
The denominator moves. You scope a push at 186 findings, scanning continues, and by the time the team has closed 40 the total reads 210. The burndown never reaches zero and nobody can say whether the work is going well. A frozen campaign fixes its cohort at the moment you commit to it.
Done is claimed, not observed. A ticket closes, a row turns green, and nothing checked. Vulnetix closes an item when a later scan of the same repository no longer reports it, and records which scan run proved it. Closures without that evidence are counted, and reported, separately.
A finished campaign looks like a broken one. A scope with a typo in a repository name matches nothing, and an empty burndown is indistinguishable from a completed one. Repository names are resolved against real repositories when you save, and a name that resolves to nothing is refused rather than stored.
What counts as finished
Pick one criterion or several, joined with all or any. Every criterion that works by absence requires a scan newer than the moment the item joined the campaign, because a repository nobody has re-scanned is silence rather than success.
Gone from later scans
The most recent scan of the repository no longer reports that finding.
Moved to a safe version
Gone from a later scan, and the package has moved at or past the fix version recorded when the item was admitted.
On a supported release
The installed version sits on a release the upstream still supports, or on the latest one published.
Package removed
The dependency is no longer present in the newest scan of its repository.
On the latest version
Packages with no upstream authority stay open rather than being assumed current.
No fixable advisory left
The installed version carries no remaining vulnerability that has a fix available.
Fix confirmed by a scan
The scanner reported the finding as fixed and named the run that verified it. The strongest evidence available, so it closes an item whatever else you configured.
What the campaign reports
Burndown by the severity each item carried when it joined. Verified closures against claimed ones. Mean and median time to remediate, with a weekly series. SLA posture against your remediation policy windows and their grace allowances, ungraded when no policy is set. Net flow of items joining against items closing. The full disposition and SSVC vocabulary for the period. Issues and pull requests linked to the cohort.
What the estate already knows about this work
A backlog of 186 findings is not 186 equal pieces of work. Campaigns surface file complexity and authorship concentration for the code being touched, whether a patch exists at all, how far each version has to move against your own autofix ceiling, the dependency ranges an upgrade has to satisfy, who can actually merge in the repositories in scope, which contributors are still active, which suppressions expire mid-campaign, and what you have already published as VEX.
When the fix does not exist yet
Part of most campaigns has nowhere to go. Those items stay open and the campaign shows what can be done instead: Snort and YARA rules matched to the CVEs in the cohort, ATT&CK mitigations and D3FEND counter-techniques, package firewall entries already blocking the packages involved, and the quality gate conditions ready to switch to blocking once the backlog is clear.
Questions people arrive with
What is a remediation campaign?
A named, time-boxed push to drive a chosen set of security work to a defined finish, with the set fixed at the start so progress can be measured against it. Different organisations call it a remediation campaign, a risk reduction sprint, a debt liquidation exercise or an eradication programme. The mechanics are the same.
How is this different from a saved filter or a dashboard view?
A saved filter re-answers the question "what matches today". A campaign records which items were admitted, when, on whose authority, and what later observation closed each one. That is what lets you show the work afterwards rather than only look at the present state.
What happens when a finding is re-scanned and gets a new identifier?
Cohort membership is keyed on the identity that survives a re-scan, being the repository, package and advisory identifier together, rather than on a database row that is re-minted on every scan and eventually purged by retention.
Can a campaign cover a repository Vulnetix has never scanned?
Yes. Type the name and it is resolved when you save: first against repositories already stored, then against the public forge, then a generic git probe for other hosts. A repository that exists is ingested so the campaign can bind to it. One that exists nowhere is refused, with the reason shown against the field.
Does freezing the scope mean new findings are ignored?
They are not part of that campaign. They still appear everywhere else in Vulnetix, and a campaign set to allow scope creep will admit them on its next evaluation. Freezing is a choice about what the burndown measures, not about what gets scanned.
What if a scan never runs again on a repository in scope?
Nothing closes. Criteria that work by absence require a scan newer than the moment the item joined, because a repository nobody has re-scanned proves nothing. Reading silence as success is the failure mode this guards against.
Read the launch write-up in the Campaigns announcement, see how the queue is ordered in Risk Prioritization, or how the estate is mapped in Threat Model and Tech Stack Graph.