The Milestone Nobody Asked For
Late 2025 brought a grim milestone: the CISA Known Exploited Vulnerabilities Catalog crossed 1,200 entries. I should probably feel relieved that someone finally made a canonical list of actively weaponized exploits. Instead, I feel like I’m watching a doomsday counter tick upward while most organizations are still arguing about whether they have time to apply patches before lunch.
Here’s what makes this number matter beyond the headline: if you work for a federal agency, you have 15 days to patch anything marked critical in that catalog under BOD 22-01. Fifteen days. That’s the regulatory reality now. The rest of us are expected to move faster too, though nobody’s quite sure exactly how fast.
I’ve been doing this long enough to remember when 1,200 CVEs meant you could actually read through them all in a month if you really tried. Now? The National Vulnerability Database processed over 40,000 new CVEs in 2024 alone, a 38% jump from just two years prior. Your automated triage pipelines are drowning. Mine are drowning. We’re all drowning, and we’re pretending the water is fine.
The Exploitation Timeline Just Got Worse
I pulled the Verizon 2025 Data Breach Investigations Report last month and actually had to walk away from my desk for a bit. The median time from CVE publication to active exploitation? Five days in 2024. Five. That was 32 days back in 2021. We’ve compressed the window where defenders can actually do something by 84% in roughly four years.
Think about what that means in practice. Your team finds out about a vulnerability on a Tuesday. Your patch management tool processes it on Wednesday, assuming the vendor has even released a fix yet. Your change advisory board meets on Thursday. You stage the patch in a non-production environment Friday morning. Maybe, if the stars align and nobody has a meeting conflict, you push it to production the following Tuesday. By then, attackers have had eight days to systematically probe your infrastructure.
This isn’t theoretical anymore. It’s just the operating environment. When January 2026 rolled around, CISA added 47 new actively exploited vulnerabilities to the catalog in a single month. Wrapped up in that batch were multiple zero-days hitting Palo Alto Networks PAN-OS and Ivanti Connect Secure, both already addressed in vendor bulletins. The patch existed. People just hadn’t deployed it yet.
The Patch Exists (That’s Not The Problem)
A 2025 study from Tenable landed in my inbox and confirmed something I’ve suspected for years: 60% of breaches analyzed involved a known vulnerability where a patch had been available for more than 30 days. Not 30 hours. Not 30 minutes. Thirty days of publicly available software that could have prevented the breach entirely.
This is the part that genuinely infuriates me, because it’s not a technical problem. Your team knows how to patch systems. Your tools can deploy updates. The barrier is organizational friction. It’s the change approval process that requires three different stakeholders to sign off. It’s the legacy application that breaks when you update its dependencies. It’s the business unit that can’t tolerate any downtime, even at 2 AM on a Sunday.
I spent a night last year debugging why a critical patch couldn’t roll out to a specific cluster. The answer? A single application owner who hadn’t responded to emails in six weeks and held veto power on production deployments for their systems. One person. One forgotten escalation email. Suddenly you’ve got a 45-day window where your infrastructure is deliberately vulnerable because the org chart is broken.
The 1,200 vulnerabilities in the KEV catalog are just a list. The real problem is that most organizations still treat patching like a quarterly project instead of continuous operational hygiene.
What Actually Needs To Change
You need to be honest about your risk tolerance. Not in meetings where you say the right things to auditors. Actually honest. If you can’t patch something within five days of disclosure, you need either engineering hours to build redundancy, business justification to accept the risk, or admission that your process is fundamentally broken.
Automate the triage. Stop having humans manually review whether CVE-2026-00001 applies to your infrastructure. Your security operations center is not a unique snowflake. If a CVE affects PAN-OS and you run PAN-OS, it affects you. Build systems that can tell the difference between “relevant to us” and “not relevant to us” without a human in the loop.
Decouple patch testing from patch deployment for non-critical systems. Yes, you should test. No, you do not need to stage every single security update in a production-like environment for 72 hours before pushing it live. Some risk of breakage is preferable to certain risk of exploitation.
Make patch deployment a first-class engineering responsibility with dedicated time and headcount. Not a thing your overworked infrastructure team does while also handling alerts and new feature deployments. It’s either important enough to matter, or it’s not. Right now, most organizations pretend it matters while structuring their teams as if it’s an afterthought.
Where This Actually Lands
The KEV catalog will hit 1,500 entries someday, probably sooner than anyone wants. The exploitation timeline will compress further because attackers keep getting better at automation. Meanwhile, the number of CVEs published annually will only grow, and most will be complete noise for your infrastructure.
You can’t fix all of this. Your organization’s change management process won’t suddenly become frictionless because I wrote it in a blog post. But you can fix the parts you control. You can stop pretending your patch management process is fine when it demonstrably isn’t. You can build feedback loops that show you exactly where delays happen and push back on the ones that don’t serve genuine operational safety.
The attackers are five days away from exploiting your disclosed vulnerabilities. Your competitors are probably one day faster at patching than you are. The gap is narrowing or widening depending on your choices right now.
What does your actual patch timeline look like? Are you willing to measure it and own the results? Drop a note in the comments if you want to talk about how you’ve tackled this problem at scale.
