One Million Vulnerabilities and Counting: Why Patching Is Not a Strategy

Gartner recently projected that by 2030, organizations will face more than one million documented vulnerabilities every year. I read that number three times to make sure I was not misreading it. A million. Annual. This is not a patching problem. It is not even a security problem in the narrow sense. It is a routine that is about to break, and most organizations do not realize their vulnerability management process is a routine at all.

The current model works roughly like this. A scanner runs. It finds a list of CVEs with severity scores. The security team triages by criticality and exploitability. A patch is tested, approved, and deployed within the SLA. If the organization is mature, the SLA is tight, the exception process is documented, and the board gets a report on mean time to remediation. Bank of America does this well. Colonial Pipeline did it poorly, and the difference between the two outcomes was not really about technology. Both had firewalls. Both had endpoint protection. One had a routine that worked and one had a routine that was paper. The breach that shut down fuel supply across the Eastern Seaboard was not a zero day. It was a known vulnerability on a legacy VPN that had no MFA and had been sitting there long enough for a ransomware gang to find it.

Feldman and Pentland wrote about organizational routines in 2003 in a paper that reconceptualized them as sources of both stability and change. Before Feldman and Pentland, management theory treated routines mostly as mindless repetition. The assembly line repeating the same motion. The checklist ticked the same way every time. Feldman and Pentland argued that every routine has two faces. The ostensive aspect is the abstract idea of the routine, the general pattern that people in the organization carry in their heads. The performative aspect is the specific actions people take when they actually perform the routine in a particular time and place. The two never perfectly match. The ostensive idea of vulnerability management is evaluate, prioritize, patch, verify. The performative reality in most organizations is wait for the scanner, look at the critical pile, scramble for the ones that have proof of concept code, hope nothing explodes during the change window, and quietly defer the medium severity ones until the next audit notice. This gap between ostensive and performative is not a bug in the theory. It is the mechanism through which routines change over time. Every time someone performs the routine differently, they introduce variation that might become the new standard.

A million vulnerabilities per year breaks this routine structurally. Even with automation, even with AI triage, no human team can evaluate, prioritize, and patch a million items. The math does not work. An organization with a hundred security analysts each handling ten thousand vulnerabilities per year would need each analyst to close roughly forty per day. Forty per day is not realistic for any vulnerability that requires judgment, testing, or exception handling. The ostensive aspect of the routine is going to stay the same, patch what matters within SLA, while the performative aspect collides with a volume that makes the SLA meaningless. The gap widens until the routine is no longer doing the job it was designed for. This is precisely the situation where Feldman and Pentland would predict that the routine either transforms or collapses.

The firms that survive this shift will not be the ones that patch faster. The ones that survive will be the ones that reconfigure their entire approach to vulnerability, and that is where dynamic capabilities theory enters the picture. Eisenhardt and Martin argued in 2000 that dynamic capabilities are specific and identifiable organizational processes that integrate, reconfigure, gain, and release resources as markets change. Product development is a dynamic capability. Strategic decision making is one. Alliancing is one. Each of these is a routine, but a routine about changing other routines. The distinction matters enormously for vulnerability management. Patching is an ordinary capability. It does the thing. It finds a vulnerability and fixes it. A dynamic capability for vulnerability management does not patch. It changes how the organization approaches vulnerability in the first place. It reconfigures the software architecture to reduce the attack surface so that fewer vulnerabilities exist to patch. It renegotiates contracts with vendors to require secure-by-default configurations. It restructures the development pipeline to catch classes of vulnerability rather than individual instances.

I wrote about preemptive cybersecurity separately, about the three Ds, Deceive, Deny, Disrupt, and about Protection Motivation Theory. That post was about how to make organizations act on predicted threats. This post is about something more fundamental. The preemptive approach only works if the organization can change its vulnerability routine from reactive to architectural. Buying deception technology does not change the routine. The scanner still runs. The triage still happens. The patch still deploys. The technology just adds another layer on top of the same broken process. The routine has to change at the ostensive level, not just at the performative level. The abstract idea of what vulnerability management is must shift from find and fix every flaw to design systems that have fewer flaws worth finding.

The Equifax breach is the clearest example I know of a routine failure that looked like a technology failure. The vulnerability was in Apache Struts, a known CVE with a patch available months before the breach. Equifax had scanning tools. Equifax had a patch management policy. The ostensive routine existed on paper. The performative routine failed because the specific person whose job it was to apply that patch did not know about the vulnerability, or the patch process broke down in the handoff between the scanning team and the server team. The routine as performed did not match the routine as designed. This is not unusual. Leonardi, citing Feldman and Pentland directly, showed that flexible routines almost always diverge from their ostensive pattern because people working with flexible technologies constantly adapt their actions to local constraints. The gap is normal. It becomes dangerous when the volume of vulnerabilities grows faster than the organization can adapt.

Teece defined dynamic capabilities in 1997 as sensing, seizing, and transforming. Sensing detects new threats. Seizing mobilizes resources to address them. Transforming reconfigures the organization around the new approach. Most cybersecurity teams are good at sensing. They run threat intelligence feeds, monitor CVE databases, and subscribe to vendor alerts. Sensing is abundant. The gap is in transforming. Transforming vulnerability management means changing the resource portfolio away from patch orchestration and toward preemptive architecture. It means hiring architects who can reduce attack surface rather than hiring more analysts to process CVEs. It means replacing the metric from vulnerabilities remediated within SLA to vulnerabilities avoided through design. This is not a typical IT operations change. It requires reconfiguring the relationship between the security team, the development team, the procurement team, and executive leadership. That reconfiguration is the dynamic capability, not the individual actions.

I think the vulnerability count is going to exceed human capacity within two or three years, not five. The rate of discovery is accelerating because more code is being written by more people using more tools, and AI generated code introduces classes of vulnerability that existing scanners barely catch. Organizations that keep investing in faster patch workflows are making a bet that does not hold. The velocity is going to outrun the machinery. The only viable response is a level change, moving from reactive vulnerability management to preemptive architecture. That is not a tool purchase. It is a routine reconfiguration, a dynamic capability that changes what the organization means by vulnerability management in the first place. The ostensive idea has to shift. If it does not, the performative gap will keep widening until the breach everyone feared becomes the breach everyone explains with the same post mortem. We knew about the vulnerability. We just did not get to it in time.