Security vulnerability remediation is a five-stage loop: detect, triage, assign, fix, and verify, with severity-based SLA clocks running from the moment of triage and prioritization driven by exploitation evidence rather than raw CVSS scores. Programs fail not because scanning is hard but because findings never acquire an owner and a deadline. If your process ends at "the report was sent," you have a detection program, not a remediation program.
The gap is measurable. Most organizations detect the vast majority of the vulnerabilities they are eventually breached through; the finding sat in a backlog with no clock attached. This post lays out the process, the prioritization model, and SLA numbers that survive contact with an engineering roadmap.
What does the vulnerability remediation process look like?
Five stages, each with a named owner:
Detect. Scanners produce raw findings continuously: SCA on pull requests, container scans on builds, DAST on releases, network scans on schedule. Detection is table stakes and it is the only stage most tooling budgets fund.
Triage. A human or a policy engine confirms the finding is real, reachable, and in scope, then stamps it with a severity and starts the SLA clock. Triage is where false positives die; skipping it poisons every downstream stage because engineers learn the queue is noise.
Assign. The finding routes to the team that owns the affected code or host, not to a central security queue. Ownership mapping (repository to team, host to service) is boring infrastructure that determines whether remediation takes days or quarters.
Fix. Upgrade the dependency, patch the host, change the config, or apply a compensating control. For dependency findings, the fix is usually a version bump that SCA tooling can propose automatically, which is why dependency debt is the fastest category to burn down.
Verify. The next scan cycle confirms the finding is gone, and only then does the ticket close. Closing tickets on developer say-so quietly rots the data your metrics depend on.
How should you prioritize the backlog?
CVSS alone is a poor sort key: a large share of CVEs are scored high or critical, while only a small fraction are ever exploited in the wild. Prioritize on evidence instead, in this order:
- Known exploitation. Anything in CISA's Known Exploited Vulnerabilities catalog goes first; the debate is over. CISA's BOD 22-01 gives US federal agencies hard due dates for KEV entries, and the catalog is a free, high-signal feed for everyone else.
- Exploit likelihood. EPSS scores estimate the probability a CVE is exploited in the next 30 days. Sorting by EPSS moves the handful of genuinely dangerous findings above the sea of theoretical ones.
- Reachability and exposure. A critical CVE in a function your code never calls, on a host with no network path, outranks nothing. Reachability analysis and asset exposure data are the biggest noise reducers available.
- Blast radius. Crown-jewel systems and internet-facing services get tighter clocks than internal batch jobs, even for identical CVEs.
Compressing these into a single risk score per finding is exactly the kind of policy a platform should automate; the goal is one ranked queue per team, not a philosophy seminar per ticket.
What SLA windows actually work?
Common baseline windows, measured from triage, that mid-size engineering organizations sustain:
- KEV-listed or actively exploited: 48 hours to mitigate, 7 days to fully remediate
- Critical (internet-facing): 7 days
- Critical (internal) and High (internet-facing): 30 days
- High (internal): 60 days
- Medium: 90 days
- Low: best effort, reviewed quarterly
Two rules keep SLAs credible. First, publish the exception path: a documented risk acceptance with an expiry date, signed by the service owner. Exceptions without expiry dates are how backlogs calcify. Second, track SLA attainment as a percentage, not as a demand for perfection; teams that hit roughly 90 percent on-time are performing well, and a dashboard showing 100 percent usually means clocks are being reset.
Why does security vulnerability remediation stall?
Three recurring failure modes. Unowned findings: the scanner reports against an image or host no team claims; fix the ownership map before buying more scanners. Upgrade fear: teams defer dependency bumps because they cannot predict breakage; smaller, more frequent upgrades and good test coverage are the remedy, and the cost curve strongly favors staying current. Duplicate queues: four tools reporting the same OpenSSL CVE four ways quadruples apparent workload; deduplicate findings across scanners before they reach engineers. For deeper material on backlog burn-down tactics, our blog archive covers prioritization case studies.
FAQ
What is a reasonable MTTR for critical vulnerabilities?
Sustained top-quartile programs remediate internet-facing criticals in under two weeks median. If your median is over 60 days, fix triage and ownership before tightening SLA numbers, because the clock is not the bottleneck.
Should SLAs start at detection or at triage?
Triage, provided triage itself has an SLA (48 hours is typical). Starting clocks at raw detection punishes teams for scanner noise; starting them at triage without a triage SLA lets findings idle unexamined.
How do we handle findings with no available patch?
Apply a compensating control (WAF rule, network restriction, feature flag), document it as a time-boxed exception, and track the upstream fix. The SLA clock pauses only if the compensating control demonstrably removes exposure.
Is 100 percent remediation the goal?
No. The goal is that exploited-in-the-wild and high-likelihood findings never age past their windows. Chasing the long tail of low-severity findings consumes the capacity you need for the ones that matter.