The Patch Paradox

1For decades, the security of everyday software has rested on an uneasy bargain. Programs are too large and too old to be free of mistakes, so the people who maintain them accept that flaws will be found, and try only to find them first. When a defender discovers a weakness, the usual practice is to fix it quietly, publish the repair, and then explain what was wrong. The arrangement has never been perfect, but it has worked well enough because finding a serious flaw used to be slow, skilled and expensive.

2That assumption is now fraying. Software that can read code at enormous speed is being used to hunt for weaknesses, and it is proving good at the job. In recent weeks, defenders have had to respond to several serious flaws in quick succession, some of them in tools so widely used that almost every organisation depends on them somewhere. Many of the discoveries appear to have been made with the help of artificial intelligence. The same tools, of course, are available to anyone.

3The difficulty lies in what happens after a flaw is found. A repair is itself a kind of confession. Once a fix is published, a capable attacker can compare the old version of a program with the new one and work out precisely what was changed, and therefore what was broken. Systems that have not yet been updated become easy targets, and in any large organisation there are always some that have not. The moment of disclosure, in other words, starts a race between those installing the fix and those studying it.

4Defenders have tried to manage that race by warning users in advance: announcing that a serious flaw exists, and that a repair will follow shortly, so that administrators can stand ready. The approach assumes that details can be kept private until the patch arrives. It is a fragile assumption. A careless post, a leaked demonstration or a premature release can hand attackers the information early, and machines that can analyse code quickly shorten the time they need to turn a clue into a working attack. In the most serious cases, authorities have advised organisations to switch systems off altogether until they can be repaired, a remedy almost as disruptive as the threat.

5None of this means the old bargain should be abandoned. Keeping flaws secret indefinitely would leave users exposed to anyone who found them independently, and secrecy has a poor record of lasting. What is changing is the arithmetic of time. When flaws were scarce and slow to exploit, defenders could afford a leisurely cycle of discovery, repair and announcement. When they are plentiful and quick to exploit, every stage must be faster, and the slowest participant, often the organisation that updates its systems only once a quarter, sets the level of risk for everyone connected to it.

6The deeper lesson may be that security is becoming less a matter of building flawless software, which was never achievable, than of how quickly a whole community can learn of a problem and act on it. The question for defenders is no longer simply whether they can find a weakness before their adversaries. It is whether they can spread the remedy faster than they spread the news.