There’s a six-part series on the NetFoundry blog with a title that’s becoming only more apparent as we move further into the Age of AI: You Will Never Patch Fast Enough. Here’s the Math.
It’s written by Jack Poller. Yes, his title says VP Product Marketing, but he has a long history as a developer, so he’s got first-hand experience with what fixing software used to be like, and an educated view into what it’s like now. So the “here’s the math,” part of the title makes it clear that this is an article written by someone who’d rather show you the arithmetic than the adjectives.
Jack kicked off the series on our blog yesterday, and here’s my summary:
The numbers
From Verizon’s 2025 DBIR and FIRST’s mid-year forecast:
- Disclosures: 40,000+ CVEs in 2024, up 38% year over year. FIRST’s June revision puts 2026 near 66,000, which is considerably higher than the February projection of 59,427, and running about 46% above that baseline through April.
- Remediation: for the edge and VPN device vulnerabilities DBIR studied, a median of 32 days to close, and only 54% fully closed at all. The average for that set was over half a year (209 days).
- The median time from disclosure to exploitation was five days. Exploitation as a breach vector rose 34% year over year and factors into 20% of breaches. Edge and VPN devices went from 3% to 22% of studied breaches in a single year.
Five days versus 32 days, on the same population of assets. There are some levers available to you that can cut that time down to 25 days (more analysts, tighter change windows), but that reduced time is still five times as long as the disclosure-to-exploitation time.
FIRST attributes the climb to 66,000 CVEs to three structural drivers and not just one:
- AI-assisted discovery
- A 449% jump in GitHub Security Advisory volume
- A 3,119% increase in VulnCheck acting as CNA of last resort
The VulnCheck figure is largely a backlog of already-existing vulnerabilities finally getting IDs assigned. FIRST’s interpretation is that this reflects better discovery and reporting rather than software getting worse. In my opinion, this emphasizes Jack’s point: Even flaws that don’t count as “new” are still going to end up in your queue.
Capacity and latency are different problems
A key part of Jack’s post is the section on volume versus risk. If you filter all those CVEs for things that are actually being exploited, such as CISA KEV entries or or EPSS above 10%, the actionable burden is fairly flat, and it’s a workload that’s manageable with some smart triage. If your team is well-run team, they can 66,000 disclosures without extra headcount, simply because most of them will never be weaponized against anyone.
But you’ll still be left with the set of vulnerabilities attackers have already decided are worth building for. That’s the slice with the shortest clock on it. Prioritizing well gives you a smaller list that burns faster.
So there are two different questions here, and they have different answers:
- Can my team absorb the workload? Sure, with good triage.
- On the items that survive triage, can I close before exploitation? Median five days against median 32.
Getting better at the first question doesn’t change the answer to the second one. In systems terms it’s problem of service-time rather than throughput. You can have a perfectly stable queue and still blow every deadline in it.
Where the series goes
Jack’s argument is that same as WOPR from the movie WarGames: Don’t play games you can’t win. In practical security terms, it’s better to make the asset unreachable, so an unpatched flaw has no network path to it. The CVE stays open in your scanner, but the exposure doesn’t exist.
NetFoundry calls this vulnerability cloaking, and parts 2 through 6 in Jack’s series will cover risk-acceptance waivers, the technical case, assets that can never be patched (EOL systems, plus everything not yet disclosed), the CFO math, and a vendor checklist.
The honest limit, because I’d rather say it than have it said at me: this helps for things that shouldn’t be broadly reachable in the first place. Your public web front end has to answer the internet and no overlay changes that. Where it bites is the large category of stuff that’s internet-reachable for reasons nobody can currently articulate: management interfaces, internal APIs, appliance admin panels, that one jump box. Which, per DBIR, is exactly the category that went from 3% to 22%.
Once again, here’s the article: You Will Never Patch Fast Enough. Here’s the Math.
