This is the nearest of near-misses. Anyone who suggests this was any kind of success is a fool. No system caught this, it was luck and individual heroics. That's not acceptable when unauthorised access to ~every server on the internet is on the table. We need to find a way to do better.
One factor in this incident was deep, unexpected dependency chains. I wish distributions would start taking a more minimalist approach to the options they enable in the default packages they ship.
What fraction of the sshd userbase actually needs Kerberos or SELinux (which also depends on liblzma) enabled? Put that stuff in an alternate package and reduce the exposure for the rest of your users. Fewer dependencies means less attack surface and less supply-chain risk
Few of the mooted software-supply chain defences would have prevented this, as the attacker was a (relatively) long-term maintainer, was not averse to using sockpuppet accounts and was careful to hide their exploit from automated tools.
Worse, many of the solutions being offered increase the workload on maintainers. But maintainer burnout was a key factor in this incident. We need to find a way to support maintainers while being proscriptive or parentalistic.
This won't be the last sophisticated and methodical OSS supply-chain attack. The actor(s) behind xz are probably already learning their lessons ahead of their next attempt. Indeed, xz might not be the only attack they had in progress.
The next one is going to be more carefully operated and harder to spot. How are we going to stop it?