It’s been nearly two years since Andres Freund’s accidental discovery of the xz Utils backdoor sent shockwaves through the open source community. This week, the OpenSSF published their annual report on open source supply chain security, and the findings are a mixed bag. We’ve made real progress in some areas, but the fundamental vulnerabilities that enabled the xz attack remain largely unaddressed. As someone who’s relied on open source infrastructure for my entire career, this hits close to home.
What the OpenSSF Report Found#
The numbers tell an interesting story. Adoption of SLSA (Supply Chain Levels for Software Artifacts) frameworks has roughly tripled since the xz incident. More projects now publish SBOMs (Software Bill of Materials), and the Sigstore ecosystem has seen massive growth — over 40 million signatures recorded in the public transparency log. Package registries like npm, PyPI, and crates.io have all implemented or strengthened mandatory two-factor authentication for maintainers of popular packages.
These are genuine improvements. Before the xz incident, supply chain security felt like an abstract concern that security teams worried about and developers ignored. Now there’s real tooling, real adoption, and real investment. The OpenSSF’s Scorecard project rates over 1.2 million repositories, giving consumers visibility into the security practices of the software they depend on.
But here’s the uncomfortable truth: none of these measures would have prevented the xz attack.
The Social Engineering Gap#
The xz backdoor wasn’t a technical exploit of a build system or a compromised dependency. It was a multi-year social engineering campaign where the attacker built trust within the project community, gradually took over maintenance, and then introduced the backdoor through a series of seemingly innocuous changes. No SBOM, no code signing, no scorecard would have caught this because the attacker was the trusted maintainer.
This is the hardest problem in open source security, and we still don’t have good answers. How do you verify the intentions of a contributor? How do you distinguish a helpful new maintainer from a sophisticated threat actor playing a long game? The uncomfortable answer is that you often can’t.
Some projects have responded by requiring multiple maintainer sign-off for releases, which helps but also increases the burden on already-overworked volunteers. The Linux kernel has long had a culture of rigorous review, but most open source projects don’t have the contributor base to sustain that level of scrutiny.
The Maintainer Sustainability Crisis#
The deeper issue that the xz incident exposed — and that we still haven’t addressed — is maintainer sustainability. Jia Tan was able to take over xz Utils in part because the original maintainer was burned out and struggling with mental health issues. This isn’t unique to xz; it’s the default state of countless critical open source projects maintained by one or two unpaid volunteers.
The OpenSSF and Linux Foundation have launched funding programs, but the scale doesn’t match the problem. Thousands of projects that form the foundation of modern infrastructure are maintained by individuals who do it in their spare time for no compensation. These maintainers are single points of failure, and they’re exhausted.
Some companies have stepped up. Google’s Assured Open Source Software program now covers over 2,000 packages with paid security review. GitHub’s Sponsors program has grown, and Tidelift continues to pay maintainers for security maintenance. But these efforts collectively cover a tiny fraction of the open source ecosystem.
Technical Mitigations That Actually Help#
While we can’t solve the social engineering problem completely, there are technical approaches that reduce the blast radius of a compromised maintainer. Reproducible builds — where anyone can independently verify that a binary was built from the claimed source code — would have caught the xz backdoor, since the malicious code was injected during the build process, not visible in the source repository.
Projects like Reproducible Builds (reproducible-builds.org) have been advocating for this for years, and adoption is growing but still limited. Debian now has over 95% of packages reproducible, which is impressive. But most software distribution channels don’t verify reproducibility, making it a theoretical rather than practical defense.
Another promising approach is build provenance attestation — cryptographic proof of how, when, and where a software artifact was built. GitHub Actions now generates SLSA provenance attestations automatically, and npm has started verifying these attestations during package installation. This creates an auditable chain from source code to deployed artifact that’s much harder to subvert.
My Take#
Two years after xz, I’d give the industry a C+ on supply chain security. We’ve built better tools, adopted better practices, and raised awareness. But we haven’t addressed the root causes: maintainer burnout, underfunding of critical infrastructure, and the inherent trust assumptions in open source collaboration.
The cynical view is that we’ll forget about supply chain security until the next major incident. I hope that’s wrong, but the pattern is familiar — a crisis drives investment, attention fades, investment slows, and the cycle repeats.
What can you do individually? Audit your dependency tree. Know which packages you depend on and who maintains them. Contribute back — not just code, but funding, bug reports, documentation. And if you’re building security tools, focus on the maintainer experience. The best security measure is one that maintainers actually adopt because it makes their lives easier, not harder.
The open source ecosystem is the most extraordinary collaborative achievement in the history of software engineering. It deserves better than the neglect we’ve given it.
This is part of my ongoing Security in Practice series, exploring real-world security challenges and practical responses.