The Patch Was Never the Hard Part
A vulnerability that's been open for years looks like negligence. Pull the changelog and it's often the opposite: the fix went in early, got reviewed, got tagged, and sat in a release nobody shipped.
The patch itself is rarely the hard part. Closing a hole in something widely deployed usually means removing an insecure default or rejecting a config value that used to be accepted and isn't anymore. That's an afternoon of engineering, sometimes less. What it isn't is free. The change breaks something that currently works for somebody currently running the old thing.
So the real question the fix raises isn't whether it's correct. It's how many installs stop working the moment it ships. Somebody has to run that count: customers still pointed at the old cipher suite, the old handshake, none of whom did anything wrong, all of whom will file a ticket the day the update lands. That number is knowable, immediate, and has names attached to it. The number of people who eventually get hurt by leaving the hole open is real too, but it's diffuse, probabilistic, and dated sometime later. Given a choice between a certain cost today and a probable cost later, an organization picks later. Every time.
That's the actual mechanism, and it isn't laziness. A plant running a control system for twenty years budgeted for twenty years of uptime, not twenty years of patches, and nobody on staff wants to trade continuous operation for a fix nobody asked for. Enterprise software sits behind change-control boards that treat a protocol version bump as its own migration project with its own line item, so the fix waits for a fiscal year with room for it. Embedded gear is worse: the vendor stopped cutting firmware for that chip two product cycles back, so the fix exists in source control and nowhere a device will ever see it.
Waiting doesn't reliably solve this either. You'd expect the blocked population to shrink as old hardware dies and gets replaced, until the compatibility bill comes due on its own. Sometimes it does. Just as often it doesn't, because whoever stamps out new installs keeps cloning the same golden image the fix was supposed to replace. New customers show up running the exact configuration the patch was written against, years after the patch existed, because nobody ever updated the thing that gets copied. The vulnerable population isn't aging out. It's being replenished by people who were never given the option to start clean.
None of this is a story about careless engineers or a broken disclosure process. The engineers did their job on schedule. What never got built is the decision above them: the authority to say a version is over, that support for it ends on a date, and that everyone still running it upgrades or gets left with the hole intact. That's a signature on a policy, not a code review, and every incentive in an organization points toward deferring it.
The person who gets breached later is a statistic. The person who loses functionality today calls support and asks for a manager. Given that comparison, the fix waits, correctly documented, correctly reviewed, freely available, for however long it takes someone to decide the second call is one they're willing to take.