The cybersecurity industry has trained us well. A vulnerability drops. Vendors scramble. Patches roll out. We patch, we patch, we patch. Security teams sleep a little easier. The cycle repeats.
This consensus is comfortable. It gives us a clear villain (the unpatched system) and a clear hero (the patch). But it's also dangerously incomplete.
The real question isn't whether we can patch faster. It's what happens when we can't patch at all, and how that reality is quietly breaking the assumptions we've built our entire defense posture around.
Consider the landscape: some of the most consequential vulnerabilities emerging right now have no patch available. Not "patch pending" or "vendor working on it." No patch, period. Some live in legacy software that vendors have abandoned. Some exist in configurations baked so deeply into enterprise infrastructure that patches would require architectural overhauls. Some sit in third-party components embedded in products so widespread that a single patch would trigger cascading failures if deployed wrong.
The Fastjson vulnerability exemplifies this. So does the Azure Automation misconfiguration that doesn't require exploitation so much as understanding how defaults actually work. These aren't fringe edge cases anymore. They're becoming the norm in complex systems.
Here's what breaks: the entire risk-management framework that assumes patches exist.
When patches are available, we can draw a line. Patched systems are on one side, unpatched are on the other. We can measure compliance. We can audit. We can prioritize based on CVSS scores and exploit availability. It's not perfect, but it's quantifiable. Organizations can report to boards: "We patched 94% of critical vulnerabilities within 30 days." Regulators can write standards. Liability frameworks can assign blame.
But what happens when the patch doesn't exist and won't exist? That entire infrastructure collapses. Suddenly there is no compliance endpoint. There's no "fixed" state to reach. The vulnerability exists, the risk persists, and both will do so indefinitely.
The discomfort this creates is real. It forces us to confront something the patching narrative lets us avoid: some vulnerabilities aren't solved, they're managed. Accepted. Lived with. And the security industry has spent decades building processes, standards, and certifications that assume the opposite.
This creates a perverse incentive structure. Organizations pour resources into patching what can be patched while ignoring or minimizing the risks from what can't. Why spend effort redesigning Azure tenant isolation when you could spend it on deployment automation? Why tackle vendor abandonment when you could upgrade to the newest product? The patchable vulnerabilities are visible, measurable, and reportable. The unpatched ones are just noise.
But they're not noise. They're features of the systems we've built. They're structural.
The real security challenge isn't becoming visible until we stop measuring success by patch velocity. It's the vulnerability that will outlive its discoverer. It's the design flaw buried in a protocol used by billions. It's the default setting that no one will ever change because changing it breaks too many downstream dependencies.
These vulnerabilities don't need us to move faster. They need us to think differently about risk, about legacy systems, about what "secure" means when patch isn't an option.
The consensus says patch faster. The harder question is: what do we do with vulnerabilities that refuse to be patched?