The xz backdoor was 28 months ago. Here is what the supply chain security scoreboard actually reads.

Twenty-eight months. That is how long it has been since Andres Freund noticed that sshd was chewing through CPU it had no business consuming on a Debian unstable box, decided to find out why instead of rebooting and moving on, and eventually surfaced a backdoor so surgically engineered that most of the researchers who analyzed it admitted it would have slipped past their own review.

The attacker, operating under the handle “Jia Tan,” had spent two years cultivating trust in the xz project. They got a maintainer role. They introduced the payload through a legitimate-looking build-system change. They had a specific target: sshd on systemd-linked systems. They came within one Debian stable release cycle of owning public-key authentication on a significant fraction of the internet.

Here is where the scoreboard reads now.

Column A: what actually got better

Reproducible builds moved from “ideologically important project that a small crew of True Believers maintained” to actual distro policy. Debian’s reproducible-builds effort had been running since 2015. As of mid-2026, over 95% of packages in Debian’s main archive build reproducibly. The number was 89% in early 2024. That delta sounds modest until you map which packages were in the remaining 11% and why they were sticky. The xz incident cleared log-jams that had been sitting untouched for years.

FreeBSD’s ports tree codified reproducible build requirements for new ports. OpenBSD, which had already been running paranoid build verification for a decade, mostly watched the post-xz scramble with quiet satisfaction and made no announcements, because they had nothing new to announce.

CISA’s software supply chain guidelines acquired procurement teeth. US federal contracts above certain thresholds now require SBOMs. Whether SBOMs actually catch sophisticated supply chain attacks is debatable; their value is more in forcing vendors to audit their own dependency trees, which surfaces old and unpatched transitive dependencies that would otherwise never get touched. That is real, if limited.

High-value projects under the SSH and TLS stack tightened contributor vetting. OpenSSL, cURL, GnuTLS, and others that sit in the critical path added explicit policies around new maintainer access. The specific vector xz used, a patient social engineering campaign over years targeting a burned-out unpaid maintainer, is now on the threat model for any project with this profile.

The Sovereign Tech Fund and the OpenSSF Alpha-Omega initiative moved more money to critical single-maintainer projects between 2024 and 2026 than in the preceding five years combined. Not enough money, but more money.

Column B: what did not change

The maintenance economics are structurally identical to what they were in March 2024.

The original xz maintainer was running a project that ships inside every major Linux distro and several BSDs, alone, for years, unpaid, while burning out. The attacker read this situation correctly and manufactured fake urgency through fake third parties to accelerate the trust transfer and get elevated access before the maintainer’s natural caution could slow things down.

That situation describes several hundred other projects in your dependency tree right now. Curl. Zlib. Expat. Libtasn1. The compression library your backup tool uses. The XML parser inside your LDAP client. The DNS resolver your service mesh calls. Pick your critical path and dig four layers down; you will find a project maintained by one or two people who have day jobs, are not getting paid for this, and are running on inertia.

Funding improved. It did not close the gap. The total dollars required to pay critical single-maintainer project maintainers at market rate for the work is still at least an order of magnitude beyond what OSS funding mechanisms are delivering. The gap narrowed. It is still a gap you could drive a nation-state attack through.

The thing nobody wants to say at the conference

The xz backdoor failed to deploy because one engineer at Microsoft noticed sshd was 500 milliseconds slower than it should be and had enough slack in his schedule to care. The attacker was one Debian stable release cycle away from shipping this to production systems worldwide.

That is not a near-miss that validates the ecosystem’s security posture. That is a near-miss that proves the security posture is a load-bearing coincidence.

Reproducible builds are good. SBOMs are fine. Tightened maintainer vetting helps. None of these address the core problem: the code that everything runs on is not audited by anyone other than the people who wrote it, and the people who write it are frequently operating without institutional support. Every other serious engineering domain treats “one tired person reviewing their own work” as an unacceptable quality gate. Open source infrastructure somehow became the exception.

I wrote about open source maintenance economics as a structural risk before most current sysadmins got their first shell account. The correct response from people with the authority to fix it was “interesting, not our problem.” That posture held until a cryptographically sophisticated multi-year campaign almost succeeded by targeting the maintainer instead of the code.

Now CISA publishes reports. Congressional subcommittees hold hearings. Budgets get allocated. The Sovereign Tech Fund exists and is funded.

I will take the wins. They are real. They are not sufficient, and the next patient attacker is already somewhere in the list of contributors on a project you depend on. The only question is whether we will be lucky again, or whether we will have built enough actual infrastructure, paid maintainers, funded audits, and enforced reproducible builds before the next one gets further than 500 milliseconds of unexplained latency.

The scoreboard is not zero. It is not where it needs to be. Both things are true.

See also: NVD and OSV: the vulnerability feed consolidation nobody asked for for the related conversation about how vulnerability data quality affects the tools that are supposed to catch these things, and ML-KEM has been the default SSH key exchange for two years. Enterprise IT just noticed. for what the SSH stack looks like after the xz cleanup finished.