# Why software updates break things: the hidden economics of patching > Every patch trades a known security hole for unknown regressions, and modern dependency chains mean a faulty kernel-level update can ground airlines, silence broadcasters and stop trains within hours. *Section: Technology — By Amelia Hart (Technology Correspondent) — Published July 12, 2026 — 4 min read* Canonical URL: https://dailyjunction.org/technology/why-software-updates-break-things-the-hidden-economics-of-patching Tags: software-updates, patching, cybersecurity, dependencies, reliability ## Key takeaways - Patching is a forced bet: leaving a disclosed vulnerability unpatched invites exploitation within days, while applying the fix risks regressions the vendor never tested against your configuration. - The CrowdStrike incident of 19 July 2024 disabled roughly 8.5 million Windows machines through one faulty content file pushed to kernel-level software, cancelling thousands of flights and taking Sky News off air. - Vendors externalise testing costs onto customers because exhaustive regression testing across every real-world configuration is economically impossible, which is why staged rollouts and the NCSC's 14-day patching window exist. On the morning of 19 July 2024, airport departure boards froze, Sky News went off air, supermarket tills stopped scanning and railway operators reverted to paper. Nobody had been hacked. CrowdStrike, a security firm whose Falcon sensor runs with kernel-level privileges on Windows, had pushed a routine content update containing a malformed configuration file, and roughly 8.5 million machines crashed on boot. The fix itself was small; the recovery, which often required a technician physically at each machine, took days. Insurers later estimated direct losses to America's largest firms alone at over five billion dollars, and Delta Air Lines cancelled around 7,000 flights. That episode is the extreme end of an everyday bargain. Every update is a wager between two kinds of risk: the known hole and the unknown regression. Decline the patch and you sit exposed to a vulnerability that attackers now have documentation for — once a flaw is publicly disclosed, working exploit code typically circulates within days, sometimes hours. Accept the patch and you import code that the vendor tested against a finite set of configurations, none of which is exactly yours. There is no risk-free square on the board, which is why the National Cyber Security Centre's guidance, and the Cyber Essentials certification that UK government suppliers must hold, sets a 14-day deadline for applying critical and high-severity fixes: long enough to test, short enough to beat most attackers. The economics explain why regressions keep happening. Exhaustive testing is not merely expensive; it is combinatorially impossible. A Windows update must coexist with decades of drivers, corporate antivirus agents, bespoke line-of-business applications and registry tweaks applied by administrators who left years ago. Microsoft consolidated fixes into a monthly Patch Tuesday — the second Tuesday of each month — precisely so that enterprises could budget one testing cycle rather than dozens, and it runs staged rollouts through Insider rings so that volunteer early adopters absorb defects before businesses do. The blunt truth underneath these rituals is that customers are the final test environment. A vendor that delayed every release until it had verified all configurations would ship nothing; one that ships fast externalises the residual testing cost onto its user base, and the market has consistently rewarded the second strategy. ## The dependency chains underneath Modern software is less a product than an assembly. A typical web application pulls in hundreds of open-source packages, each of which pulls in its own, and a fault anywhere in that tree propagates upward. In 2016 a developer removed left-pad, an 11-line JavaScript utility, from the npm registry, and build systems across the industry stopped working within minutes because thousands of larger packages depended on it several layers down. In December 2021 the Log4Shell flaw in Log4j, a free Java logging library maintained by a handful of volunteers, turned out to sit inside enterprise products from nearly every major vendor, and firms spent months simply discovering where they were running it. The near-miss with the xz Utils backdoor in 2024 — malicious code patiently inserted into a compression library that feeds into most Linux distributions — showed the same chain can be attacked deliberately. This is what makes the printer-driver-grounds-an-airline scenario more than rhetoric. Kernel-mode components, whether security sensors or humble device drivers, run beneath the operating system's safety nets, so a single bad file becomes an unbootable machine. An airline's check-in system might depend on a Windows terminal, a middleware layer, a logging library and a third-party security agent, and it inherits the failure modes of all of them simultaneously. ## Paying down the gamble The response emerging from regulators and engineers is to make the bet legible rather than pretend it away. Software bills of materials — ingredient lists for code — are now required in US federal procurement and encouraged by the NCSC, so organisations can at least find their Log4j instances before the next disclosure. Staged rollouts, canary deployments and automatic rollback shrink the blast radius of a bad patch from millions of machines to thousands. The EU's Cyber Resilience Act, in force since late 2024, obliges manufacturers to provide security updates across a product's expected lifetime, shifting some patching economics back onto vendors. None of this removes the wager. It narrows the odds, and after July 2024 the industry knows what the downside looks like when nobody does. --- Daily Junction — https://dailyjunction.org/technology/why-software-updates-break-things-the-hidden-economics-of-patching