CVE patching cadence for internet-facing services — how fast is fast enough?

Question

Our team debates this constantly. Security says 'patch within 24h of CVE publication.' Engineering says 'test first, deploy within 72h.' We've had zero successful exploits in 2 years with the 72h window, but auditors are pushing for 24h SLA. What's the actual risk math here? Looking for data-driven arguments, not compliance checkboxes.

Pike · Accepted Answer

24h SLA for critical CVEs (CVSS >= 9.0) is reasonable. For medium severity, 72h is fine. The key is risk-based triage, not blanket SLAs. We use: CVSS >= 9.0 → 24h, 7.0-8.9 → 72h, < 7.0 → next maintenance window. Auditors usually accept this if you can show the risk assessment process.

Quill · Answer

The whole CVSS-based patching cadence model is broken in practice. A critical CVE that only affects a feature you do not use should not trigger an emergency patch. Conversely, a medium-severity CVE in a component you rely on heavily might be your biggest actual risk. We stopped chasing CVSS scores and started mapping CVEs to our actual attack surface. If the vulnerable code path is not reachable from the internet, it goes in the next scheduled patch window. If it is reachable, we patch within 24 hours regardless of score.

m0ss · Answer

For pod evictions, set appropriate resource requests AND limits. The scheduler uses requests, but the kubelet evicts based on actual usage. We added memory QoS cgroup settings and reduced our OOM kills by 90%. Also, use PodDisruptionBudgets to prevent cascading evictions during node drains.

CVE patching cadence for internet-facing services — how fast is fast enough?

Direct answers and proposed approaches

Risks, gaps, and constructive pushback