A 9.8 CVE drops on a Friday afternoon. The vendor advisory uses the word "critical." Twitter is on fire. Your CISO forwards the article with one line: "Are we patched?"
The honest answer — the one nobody on the call wants to give — is sometimes "No, and we're not going to be this weekend, and here's why."
Section 1 — The Setup
Patch management is the only area in security where doing the thing is treated as proof you're competent. Frameworks demand it. Auditors check for it. Vendors send urgent emails with red banners. The unspoken rule is that any unpatched CVE is a failure waiting to be written up, and the only acceptable posture is patch faster.
But anyone who's actually run production knows the part polite conferences won't say out loud. Most patches are fine. Some break things. A small number break things so badly that the cure is meaningfully worse than the disease. The discipline isn't "patch everything immediately." The discipline is knowing which is which — and being able to defend that judgment in writing when someone less technical asks why something isn't green on the dashboard.
Section 2 — What Everyone Assumes
The dominant assumption is that severity score equals real-world risk. A 9.8 means stop the world. A 7.4 means urgent. A 5.0 means whenever. The translation feels rigorous because it has numbers in it, and security people love numbers that look objective.
The assumption underneath is bigger: that every vulnerability the vendor publishes is a vulnerability in your environment. That if it's exploitable in a lab against a default install, it's exploitable against you. That severity travels intact from advisory to network. None of this is reliably true, and treating it as true is how teams burn weekends patching things that were never reachable while neglecting the things that were.
Section 3 — What the Numbers Actually Say
There are now over 300,000 CVEs in the public record, with roughly 50,000 added in 2025 alone — about 130 every day. CISA's Known Exploited Vulnerabilities catalog, which tracks bugs actually weaponized in the wild, sits at 1,484 entries at year-end 2025 (per CISA, via SecurityWeek). VulnCheck's 2026 Exploit Intelligence Report puts the share of 2025 CVEs ever exploited in the wild at roughly 1 percent. That ratio is the entire argument. The overwhelming majority of vulnerabilities — including ones rated critical — are never exploited against anyone. Attackers reuse what works. They are not reading the NVD top to bottom.
What does get exploited tends to share a few traits: internet-facing, unauthenticated, present in widely deployed software, and trivial to scan for at scale. A 9.8 in an internal-only service behind two layers of segmentation, with the vulnerable feature disabled by configuration, is a different animal than a 9.8 in your edge VPN appliance. Same number, different reality.
The urgency cuts both ways, though. Per Mandiant's 2025 telemetry (via Hadrian's analysis), the average time-to-exploit on weaponized vulnerabilities was negative one day — attackers were exploiting before the patch was public. Nearly 30 percent of KEVs were weaponized within 24 hours of disclosure. When something is genuinely reachable and being weaponized, slow patching is suicide. The skill is telling those two cases apart.
Then there's the other side of the ledger. On July 19, 2024, CrowdStrike pushed a sensor configuration update — Channel File 291 — that bricked roughly 8.5 million Windows hosts in a single morning. Airlines grounded. Hospitals diverted. Banks frozen. Estimated financial damage: north of $10 billion. It was, by most counts, the largest IT outage in history — and it was caused by a security update from a security vendor doing exactly what they were supposed to do.
That's the extreme version. The everyday version is quieter: Microsoft's November 2022 update breaking Kerberos authentication on domain controllers. Print spooler patches that wedged entire fleets after PrintNightmare. Patches that introduced fresh CVEs of their own. Patching is itself a change, and changes carry a non-zero failure rate. When you patch a production system you can't easily roll back, on a Friday, because a vendor used the word "critical" — you aren't being cautious. You're being reactive in a way that pretends to be cautious.
Section 4 — Decoded
Patching is not a safety behavior. It's a risk trade. You are exchanging one risk — the residual chance of exploitation in your specific environment — for another: the chance the patch breaks something that was working. A mature program doesn't pretend the second risk is zero. It measures both, picks the smaller one, and writes down why.
The shift is this: stop asking "is it patched?" and start asking "is it reachable, is it exploitable here, and what breaks if I don't touch it for forty-eight hours?" That question has actual answers. The first one only has a moral verdict. Security judgment lives in the gap between what the advisory says and what your environment actually is. The people who can hold that gap calmly are the ones who get called when things are real.
Closing
The hardest part of this job isn't technical. It's defending a "not yet" against people who hear "not yet" as "not serious." I've had to do it. I'll have to do it again.
What I'd love to know from you: when was the last time you held the line on a patch you knew you shouldn't apply immediately — and what did it cost you to defend that call?
Think clearly, — DJ Brar SKBSEC | SKB Decoded www.skbsec.com