Report vulnerability remediation from a fixed cohort of approved findings, with separate states for assigned, change proposed, change merged, reassessment pending, verified fixed, still present and inconclusive. Count a fix only when a later check supplies positive evidence that the original unsafe behavior is prevented or removed on the relevant new revision. A scanner that produces no alert after a patch has not, by itself, established closure. Publish the cohort denominator, the cutoff, the remaining open ages and any scope or deployment limits beside the percentage.
If the service was decommissioned, the code moved, or a compensating control changed exposure, the closure question changes: document what happened to the original path and all relevant reachable replacements. If that mapping is unknown, report “inconclusive” or “exposure reduced,” not “fixed.” A security leader should be able to distinguish verified corrections and closed exposure from work that merely advanced through a workflow; finding counts alone do not quantify the amount of risk removed. NIST SP 800-55 Vol. 1 emphasizes measure definitions, data quality and uncertainty; the state model below is a practical application of that principle.
Freeze a cohort before calculating a rate
Pick a reporting cutoff and identify all distinct, approved findings due for action in that period. Record their stable IDs, affected asset, original revision, due date, owner and business priority as of the cohort freeze. Do not add a finding to the denominator only after it is fixed. Do not remove a difficult finding because its due date was quietly extended. If scope or date legitimately changes, publish the change and approval separately from the original cohort.
The useful top-line rate is:
Due verified-fix rate at cutoff =
approved findings in the frozen due cohort with positive fix reassessment
--------------------------------------------------------------------------
all approved findings in the frozen due cohort
This rate describes verified closure of a named workload. It is not the probability that the application is safe, and it does not measure undiscovered issues. Show the count beside the percentage. If one finding affects three deployed services and the fix reaches only two, closure of the full finding needs the scope rule you agreed before the report; otherwise show partial deployment progress. Avoid a denominator made of scanner alerts, because duplicates, rejected claims and candidates are not the same as approved findings.
Use a state ledger that preserves evidence
| State at cutoff | What it means | What would advance it |
|---|---|---|
| Open, no change | Approved finding still has no relevant correction | Owner supplies a change or containment decision |
| Proposed or merged | A code change exists; no positive reassessment yet | Reviewer evaluates the new immutable revision against the original claim |
| Inconclusive | Reassessment lacked required path, control, scope or deployment evidence | Named owner supplies missing evidence and reviewer repeats the check |
| Still present | Reassessment finds the unsafe behavior persists | Owner revises the fix; keep original finding open |
| Verified fixed in code | Evidence shows original unsafe behavior prevented or removed on relevant new revision | Deploy and confirm artifact if the report concerns production exposure |
| Production exposure closed | Verified corrected artifact is deployed across the stated affected scope | Monitor for regressions under normal change control |
| Accepted or contained | Authorized time-bound business response or compensating control changes exposure | Review expiry, control effectiveness and underlying defect separately |
These states keep technical closure distinct from workflow and business decisions. A merged pull request may be meaningful engineering progress, but it is not a verified security result. An accepted risk may be a valid management choice, but it is not a fixed vulnerability. A source-level fix may be verified while an older vulnerable artifact remains deployed. NIST SP 800-40 Rev. 4 frames patch management as preventive maintenance and a risk response process; a reporting ledger should reflect implementation and verification, not just patch intent.
Illustrative risk example: six due items and two quiet scans
Illustrative only. The company, finding IDs, counts and dates are invented. A B2B software team freezes six approved findings due by the October cutoff. Two unsafe account-scope paths have verified fixes on new revisions and confirmed deployments. A third has a merged patch but no reassessment. A fourth no longer appears in the scanner's output after a rule-set update; the original path has not been checked. A fifth has a reassessment that cannot map a moved authorization control. The sixth remains present after a first patch.
The correct due verified-fix rate is 2/6, or about 33%. The team can also report one merged change and one attempted fix that did not work. Counting the two quiet or incomplete results as fixes would manufacture progress. If the rule-set change caused the missing alert, the original risk might remain exactly where it was. If the moved control is effective, a reviewer still needs to establish which entry points it protects.
Here is a filled one-page progress artifact:
REMEDIATION COHORT UPDATE — illustrative October cutoff
Cohort: six distinct approved findings due by 18 October 2026
Denominator owner: AppSec lead; original IDs and due dates frozen 1 October
Method: original claim compared with named new revision and relevant controls
Verified fixed in code and confirmed deployed: 2 / 6 (33%)
Merged, reassessment pending: 1 / 6
No alert after rule-set change, original path untested: 1 / 6 — OPEN
Control moved, reassessment inconclusive: 1 / 6 — OPEN
Still present after attempted fix: 1 / 6 — OPEN
Oldest remaining open item: 46 days since approval (ID AC-12).
Business priority: AC-12 remains first because it affects an account boundary;
priority owner and rationale recorded separately from technical status.
Next decisions: engineering owner schedules AC-12 rollout; security reviewer
reassesses its merged correction; platform owner maps the moved control.
Next cutoff: 25 October. Inventory and scanner-method changes listed in annex.
The 33% should not be compared with last month's rate if last month used alert count as the denominator or marked merged patches as fixed. Start a new series or restate the old cohort from evidence. State the method break plainly. NIST SP 800-55 Vol. 2 treats measurement as a program with development and implementation practices; versioning definitions is part of making a series interpretable.
Follow one shared finding through three cutoffs
Give the original six rows stable IDs before extending the example: AC-10 and AC-11 are the two verified and deployed fixes; AC-12 is merged; AC-13 is quiet after a rule change; AC-14 has the moved control; AC-15 remains present after its first patch. AC-12 is one authorization defect in a shared component used by three deployments: API-East, API-West and Export-Worker.
The reporting rule for this example is explicit: code closure requires positive reassessment of the shared correction; production closure requires the corrected behavior across all three affected deployments. A common component defect counts once, with three affected deployment rows. This rule is chosen for the exercise, not a universal finding taxonomy.
| Evidence received | 18 October cutoff | 25 October cutoff | 1 November cutoff |
|---|---|---|---|
| AC-12 shared correction | Merged; not reassessed | Positively reassessed 21 October | Same correction remains supported |
| API-East | Old artifact | Corrected, mapped 22 October | Old artifact restored by rollback 29 October |
| API-West | Old artifact | Corrected, mapped 22 October | Corrected |
| Export-Worker | Old artifact | Old artifact; upgrade delayed | Corrected, mapped 27 October |
| AC-12 production conclusion | Open, 0/3 corrected | Open, 2/3 corrected | Open again after the intervening closure; 2/3 currently corrected |
On 27 October, after the worker change, all three were confirmed corrected and AC-12's production exposure was closed. On 29 October, the mapped API-East rollback restored the affected version and the finding reopened for that deployment. Preserve both events. The 1 November snapshot cannot show a current production closure simply because a successful closure occurred during the period.
Assume the other five cohort findings retain their original technical states. The resulting totals are:
| Reported quantity | 18 October | 25 October | 1 November |
|---|---|---|---|
| Due findings with supported code fixes | 2/6 | 3/6 | 3/6 |
| Due findings currently closed across affected production scope | 2/6 | 2/6 | 2/6 |
| AC-12 closure/reopen events since prior cutoff | None | None | One production closure, one production reopen |
The code-fix numerator remains three because AC-12's corrected artifact is still supported; production reverted to an older one. A different incident in which the supposedly fixed artifact itself failed would require reassessing that code conclusion too.
Now suppose management accepts AC-15's residual risk through 15 November. The risk owner, reason and expiry are added to the response record. Neither numerator increases: acceptance did not correct the path. The accepted finding remains visible in the unresolved population, even if it moves out of the team's immediate work queue.
This view explains how a team can ship meaningful work while the current production-closure rate stays at 33%. Three deployments received the correction, then one rolled back. Counting “tickets closed this week” would hide that sequence; counting each deployment as a new vulnerability would inflate the defect count.
The technical evidence behind each positive reassessment belongs in the new-commit verification guide. For this report, the essential question is which named event authorizes each state change and which population that change affects.
Show elapsed time without hiding survivors
Teams often report average days to close. That statistic includes only closed cases and can look excellent while one material finding remains open for months. Show the age of open cohort items as of cutoff, preferably by business priority and named owner. For closed cases, show the time from approval to positive verification and, where relevant, from verification to confirmed deployment. Those are two different lead times with different owners. Do not blend them into one number without saying what it means.
If the cohort is small, list every state and age rather than a percentile. With larger cohorts, a median and an upper percentile can help, but always accompany them with the count still open and the oldest material items. Report due-date changes, risk acceptances and scope removals in a movement table. A falling backlog caused by a reclassification needs explanation; it is not equivalent to verified risk reduction.
The AppSec lead should audit one closed item per update from original claim through new-revision evidence and deployment mapping. The engineering owner should confirm the remaining due items and dates. The security leader can then tell management which risk actually changed and which decisions remain. NIST SP 800-137 emphasizes timely risk response from monitoring information; a truthful state ledger is more useful to that purpose than a flattering closure percentage.
Distinguish a scope correction from a verified repair
If AC-13 is later shown to concern a service that never deployed the affected artifact, correct that scope using positive artifact evidence. The disposition is not a fix produced by the quiet scan. Preserve the original claim, the new evidence and the reason the affected population changed. The frozen due cohort can show a corrected non-applicable item separately from verified repairs, according to its published rules.
This keeps the report useful when earlier records were wrong. Correcting an error is good measurement work, but it should not earn the same numerator as repairing an actual unsafe path. Leadership can then see both the improved inventory and the remaining engineering obligation.
Next action
Freeze the next due cohort now and agree on the closure rule with engineering. Bring the one-page ledger to the next prioritization meeting, especially the inconclusive and old open items. For the overall leadership scorecard, see which AppSec metrics show progress without hiding gaps. For the technical closure method, see how to verify that a vulnerability was fixed in a new commit.