## TL;DR
Every CVE gets a row: owner, deadline, status, and the evidence that closed it. Nothing closes on vibes. A weekly re-scan is the heartbeat that moves rows from open to verified. The register is the whole system, keep it boring and keep it current.

```text
how to track CVE remediation to completion
```

### Use this when
- CVEs get acknowledged and then quietly forgotten
- You need a remediation status report for a review or an audit
- Your team is starting formal vulnerability management from zero
- Multiple teams each own pieces of the fix and nobody has the full picture

### Not for
- Deciding which CVE to patch first (thats triage)
- Writing or applying the patch
- Scanner configuration or alert tuning

### Steps

**1. Create one register for all open CVEs.**

A spreadsheet or tracker board with columns: CVE id, affected service or repo, severity, exploitability note, owner, deadline, status, evidence link. One row per CVE per affected asset.

Expected: a single list everyone can see, no hidden backlogs.

**2. Assign an owner and a deadline to every row.**

No owner means no progress. Deadlines follow your SLA policy (critical in days, high in weeks), but every row gets a date even if it is only a review date.

Expected: zero unowned rows, zero rows without a date.

**3. Work the register weekly.**

Review every open row once a week. Owners report status: patching, waiting on vendor, mitigated, verified. Move rows that miss their deadline to an exception list with a written reason.

Expected: the register reflects reality every week, stale rows are visible.

**4. Verify with a re-scan before closing anything.**

A row closes only when a fresh scan shows the CVE gone from that asset, plus a note of the fixed version. No scan, no close.

Expected: closed rows each carry scanner evidence.

**5. Track the exceptions separately.**

No-patch-available, wont-fix, and deferred items live in an exception list with expiry dates and an approver. Exceptions get re-reviewed on expiry, they dont rot.

Expected: a short, current exception list with dates, never a silent graveyard.

**6. Report the numbers.**

Open count, mean time to remediate, SLA compliance percentage, exception count. This is the report leadership actually wants.

Expected: four numbers you can produce on demand.

### Variant phrasings

#### How do I make sure CVEs actually get fixed
One register, one owner per row, weekly review, re-scan evidence before close. Thats the whole machine.

#### Tracking vulnerability remediation across teams
Same register, owners from each team, one weekly review that cuts across teams. The cross-team visibility is the point.

#### SLA tracking for security patches
Deadlines in the register plus a weekly compliance report: how many rows closed inside their SLA window vs outside.

### Why it happens
Remediation fails at handoffs, not at patching. Someone acknowledges the alert, the fix lands in one of three repos, nobody verifies the deploy, and the alert ages out of everyones memory. The register exists because your memory and the scanners dashboard are both bad at remembering what is actually done.

### Edge cases
- **Fix landed but deploy didnt:** verify the deployed artifact, not the merged PR. A merged fix that never deployed keeps the row open.
- **One CVE across many assets:** one row per asset, or the register lies about completion. You can group them under one parent for reporting.
- **Vendor fix delayed indefinitely:** move to exceptions with an expiry and a mitigation note. Re-review on expiry, dont just extend forever.
- **Register rots because nobody updates it:** the weekly review is the maintenance. If reviews stop, the register is decoration. Automate the re-scan feed into the register so updates are cheap.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_51BV50Bdpx9mIjQa5jZyLw