The xz backdoor is sometimes offered as a verdict on open source. One side says that public contribution made the compromise possible. The other says that public code made the discovery inevitable.
Neither claim survives contact with the incident.
A patient adversary earned trust in an understaffed project, gained release authority, and hid malicious build logic in release artifacts. The compromise was not stopped by a routine review. Andres Freund found it after noticing that SSH logins were consuming unusual CPU time and taking longer than expected. His first oss-security report is worth reading because it preserves the uncertainty and careful observation of the discovery itself.
Open source did not prevent the attack. It did make the evidence unusually inspectable once something looked wrong.
That distinction is more useful than another argument about whether open or closed code is categorically safer.
Inspectability is a capability, not a guarantee
Source availability changes who can investigate and how far they can go. Freund could move from a performance anomaly to build scripts, release tarballs, object files, and upstream history without waiting for a vendor to grant access. Other researchers could check his work against the same artifacts. Distributions could compare their build paths and remove affected versions quickly.
None of that means that public code is continuously reviewed. Much of it is not. A repository can be open and still have one exhausted maintainer, weak release controls, opaque generated files, and almost no independent scrutiny. The xz campaign exploited precisely that gap between code being visible and a project being governed well. The OpenSSF and OpenJS Foundations later described similar social-engineering patterns.
Closed software is not literally opaque either. Researchers reverse engineer binaries, trace processes, compare updates, and disclose serious flaws without source access. Vendors also conduct internal reviews that open projects may lack. The difference is cost and authority: source usually makes independent analysis easier, while a closed vendor decides who sees the implementation and release pipeline.
So the defensible claim is narrow. Openness expands the population that can verify an explanation or a fix. It does not ensure that anyone will do so before deployment.
The comparison with closed incidents has limits
SolarWinds is an instructive comparison, but not a controlled experiment. CISA identified affected Orion releases from March through June 2020 when it announced active exploitation in December. That was a long and damaging compromise of a proprietary build pipeline. It shows that corporate access controls and paid engineering teams do not eliminate insider or supply-chain risk.
It does not prove that closed source always takes longer to investigate. The xz and SolarWinds attackers, targets, discovery paths, and deployment populations were different. Two famous incidents cannot isolate source availability as the causal variable.
Crypto AG makes a different point. US and West German intelligence secretly bought the company in 1970; the BND left the arrangement in 1993, while the CIA continued as sole owner until the business was sold in 2018. Earlier intelligence cooperation predated the purchase. The declassified historical record shows what can happen when customers cannot independently validate a security product and the supplier is itself adversarial.
Hardware, firmware, algorithms, ownership, and procurement all contributed. An assurance model built entirely on supplier reputation can fail for a very long time.
Kerckhoffs is relevant, but not in the usual way
Kerckhoffs’s principle says that a cryptosystem should remain secure even when its design is known, with the key providing the necessary secret. It is a sound warning against treating a hidden algorithm as the security boundary.
It does not require every software implementation to be open source. Nor does publishing an implementation make it sound. AES, TLS, and SSH have public specifications and many open implementations, but they also have proprietary implementations. Their security depends on the protocol and implementation surviving informed scrutiny, not on every codebase sharing a license.
The broader engineering habit still matters: assume that an attacker can learn how the system works. Source secrecy may add friction, but it should not be the control that protects credentials, authorization decisions, or cryptographic keys.
Source, build, and delivery are separate trust decisions
The xz incident is especially useful because it crossed the boundaries people often blur together.
- A public Git repository made development history visible.
- Release tarballs contained material that did not follow transparently from that history.
- Distribution build conditions activated the malicious path.
- Signed hashes could prove which artifact was downloaded, but not that the artifact was benign.
A reproducible build only proves that the same declared inputs produce the same output. Rebuilding a malicious release tarball can faithfully reproduce the malicious binary. To detect the xz-style mismatch, a project also needs source provenance: a verifiable relationship among reviewed commits, generated release artifacts, build inputs, and published packages. The Reproducible Builds guidance treats precise, verifiable source references as part of that chain.
Package ecosystems deserve the same precision. Linux distributions often provide signed repository metadata, versioned packages, and public packaging source. Windows also has Authenticode, HTTPS delivery, the Microsoft Store, and winget. Neither ecosystem reduces to “verified packages” versus “hope.” The useful questions are concrete:
- Who produced this binary?
- Which source and build instructions produced it?
- Can another party reproduce or meaningfully inspect it?
- How are updates authorized and revoked?
- What happens when the maintainer or vendor is compromised?
Those questions travel well across operating systems and licensing models.
What I look for now
Maintaining Mistborn in public taught me that visibility changes the quality of a technical claim. A user can challenge a firewall rule, trace the generated configuration, or show that an assumption fails on their kernel. That is occasionally uncomfortable and consistently useful. It does not replace testing or review; it gives both a larger surface on which to happen.
When I evaluate a security-sensitive dependency today, the license is only one line in the assessment. I also want to know:
- whether more than one person can approve a release;
- whether generated artifacts can be traced to reviewed source;
- whether CI and signing credentials are isolated and recoverable;
- whether downstream packagers preserve useful provenance;
- whether the project publishes clear advisories and accepts uncomfortable reports;
- whether my system can constrain or remove the dependency if trust fails.
An excellent proprietary vendor can answer many of these questions well. A neglected open project can answer them badly. Source availability still matters because it permits a kind of independent verification that contractual assurance cannot fully replace, but it is one layer of evidence rather than a verdict.
That is what the xz backdoor changed for me. It made the value of openness more specific. The security property is that when somebody notices a half-second that should not be there, the surrounding system gives them enough evidence to keep following it.