The xz backdoor is an argument for open source, not against it

After the xz backdoor was discovered, a predictable chorus emerged: “This is why open source is dangerous.” The argument goes like this: anyone can contribute to open source, so anyone can plant a backdoor. Therefore, closed source, where a company controls the code, is safer.

I think this argument is backwards. The xz backdoor is one of the strongest recent cases for open source security visibility. Not because it prevented the backdoor (it did not), but because it exposed the full mechanism quickly and enabled a coordinated global response within 24 hours. Closed-source vendors can respond quickly too, but the surrounding ecosystem usually cannot independently inspect the same evidence in the same way.

What actually happened

Andres Freund, a PostgreSQL developer at Microsoft, noticed SSH logins to a Debian Sid machine were 500ms slower than expected. He profiled sshd, traced the latency to liblzma, and found a backdoor that had been planted over a two-year social engineering campaign. He posted his findings to the oss-security mailing list. Within a day, every major Linux distribution had reverted to safe versions, CISA had issued an advisory, and the full technical mechanism of the backdoor had been publicly documented.

The backdoor was in the wild for five weeks before it was caught. Five weeks.

Let me be honest about something: the discovery was luck. Freund was benchmarking PostgreSQL, not auditing xz. He noticed a half-second anomaly and had the curiosity and skill to chase it down. This was not a systematic security review. It was serendipity: a developer with deep systems knowledge happening to notice something that did not feel right.

That is both the most inspiring and the most sobering part of this story. Open source security is not a guaranteed process. It is a property that makes lucky discoveries possible. Closed source makes that kind of independent discovery much harder. Freund did not need permission, an NDA, or a vendor relationship to investigate. He just looked.

Now ask: what happens when this occurs in closed source software?

The closed source track record

We do not have to speculate. Closed source supply chain attacks have happened, and the timelines tell the story.

SolarWinds (2020)

The SolarWinds Orion platform, closed source, enterprise network monitoring, was compromised through a backdoored build pipeline. Attackers inserted malicious code into the Orion software update process. The trojanized update was distributed to approximately 18,000 organizations, including the US Treasury, the Department of Homeland Security, and FireEye.

The backdoor went undetected for nine months.

It was discovered only because FireEye noticed their own red team tools had been stolen, which prompted an internal investigation that eventually traced the intrusion back to the SolarWinds update. Not a performance anomaly noticed by a curious developer. Not a community audit. A breach at a security company that happened to unravel the thread.

The comparison:

Nine months versus five weeks. And the xz discovery was “lucky.”

Juniper ScreenOS (2015)

In 2015, Juniper Networks disclosed that unauthorized code had been found in ScreenOS, the firmware running their NetScreen VPN appliances. The backdoor enabled VPN traffic decryption and unauthorized administrative access. It had been present for three years before Juniper discovered it during an internal code audit.

No external researcher could have found it. The firmware was closed source. The only reason it was discovered at all is that Juniper happened to audit the right code at the right time. How many similar backdoors exist in other closed source network equipment that has not been audited is an open question with no comfortable answer.

Crypto AG (1945–2018)

The most extreme case. Crypto AG was a Swiss manufacturer of encryption equipment used by over 120 governments worldwide. For over 50 years, the company was secretly owned by the CIA and the German BND. The encryption devices were deliberately weakened, allowing US and German intelligence to read the encrypted communications of allied and adversarial nations alike.

This was not a vulnerability. It was a feature, built into closed source, closed hardware systems that customers could not inspect. The operation ran for half a century. It was exposed not by a technical audit but by a joint investigation by the Washington Post, ZDF, and SRF in 2020, based on leaked CIA documents.

Fifty years. Because nobody could look inside the box.

Insight

What these examples suggest

These cases suggest that openness materially increases the discovery surface. That does not prove every open-source incident will be found faster than every closed-source one. It does support the narrower claim that public code and public teardown capability make independent discovery, verification, and shared learning much easier.

The vulnerability you do not know about

The security community settled the visibility question in the 19th century. Kerckhoffs’s principle, published in 1883, states that a cryptographic system should be secure even if everything about the system is public knowledge except the key. The principle extends beyond cryptography: security should not depend on the secrecy of the implementation. A system that is only secure because the attacker cannot see the source code is not secure; it is obscure.

This is not a theoretical position. It is the foundation of modern cryptography, protocol design, and security engineering. AES, TLS, and SSH are all secure despite their implementations being fully public. Their security comes from mathematical properties, not secrecy.

Closed source software that relies on code secrecy for security is practicing security through obscurity: the approach that the field rejected over a century ago.

When a vulnerability exists in closed source software:

• You do not know it exists until the vendor tells you (if they ever do).
• You cannot inspect the code to assess the scope or verify the fix.
• You cannot trace the mechanism; you get a CVE number and a patch, with no way to understand what was actually wrong.
• You depend entirely on the vendor’s disclosure timeline, which is driven by business interests, not your security needs.

When a vulnerability exists in open source software:

• Anyone can find it. Security researchers, users, and developers like Freund all contribute to the discovery surface.
• The full mechanism is visible. You can read the malicious code, understand the attack vector, and assess your exposure precisely.
• The fix is auditable. You can verify that the patch actually addresses the vulnerability, not just suppresses the symptom.
• Disclosure is public and immediate. There is no vendor deciding when you get to know about the risk to your systems.

Insight

Absence of evidence is not evidence of absence

The fact that fewer public vulnerabilities exist for a closed source product does not mean the product has fewer vulnerabilities. It means fewer people are looking. Every major closed source platform, Windows, macOS, iOS, Oracle Database, has a steady stream of critical vulnerabilities discovered by the small number of researchers with the resources and legal cover to audit them. The full vulnerability surface of closed source software is unknown and unknowable by design.

The honest counterarguments

The case for open source security is strong, but it is not without tension. Ignoring the counterarguments weakens the position. Here they are.

”Open source enabled the attack”

This is true. Jia Tan could contribute to xz because the project accepted external contributions. In a closed source company, there would theoretically be background checks, HR processes, and paid reviewers with accountability. The openness that enabled discovery also enabled the attack vector.

The question is which effect dominates. My argument is that, in the examples above, discovery and post-incident learning win. The xz backdoor was found in five weeks by an independent developer. The SolarWinds backdoor, planted inside a closed source company with background checks, HR, and paid engineers, ran for nine months. Corporate controls did not prevent the SolarWinds compromise. Open access did enable the xz compromise. It also enabled a much faster community response.

The attack surface and the discovery surface are the same surface. You cannot have one without the other. These examples do not amount to a universal dataset, but they do point in the same direction: broader visibility improves the odds of earlier discovery.

”Linus’s Law failed”

“Given enough eyeballs, all bugs are shallow.” But xz did not have enough eyeballs. It had one burned-out maintainer. The backdoor was specifically designed to evade the few eyes that existed: malicious code was hidden in binary test fixtures, the build system modifications were subtle, and the payload only activated during distribution package builds, not during local development or CI.

This is a fair criticism. The naive version of Linus’s Law, that open source code is automatically well-audited, is wrong. Most open source code is not audited at all. The xz project had no security review process, no second maintainer, and no corporate sponsor.

But the honest version of the argument was never “many eyes guarantee security.” It is: open code allows eyes to look. Closed code forbids it. Freund did not need a license, a contract, or a vendor relationship to trace a performance anomaly into the xz source code. In a closed source library, his investigation would have stopped at the shared object boundary. The backdoor would still be running.

The problem with xz was not that the code was open. The problem was that the project was under-resourced. That is a solvable problem, fund maintainers, require multi-party reviews, invest in the infrastructure. The “solution” of closing the code does not fix the resource problem. It just removes the possibility that someone like Freund can help.

”The discovery was luck”

Yes. Acknowledged above. Freund was not looking for a backdoor. He was benchmarking PostgreSQL. The discovery was serendipity.

But serendipity requires opportunity. Open source creates the opportunity for thousands of developers to stumble into anomalies and have the ability to investigate them. Closed source eliminates that opportunity entirely. You are left with only the vendor’s internal security team, which, in the case of SolarWinds, Juniper, and Crypto AG, was not enough.

Luck favors the system that creates more chances for lucky discoveries. Open source creates those chances. Closed source does not.

The ostrich problem

Some organizations prefer closed source specifically because they do not want to know about vulnerabilities. This is not stated explicitly; it surfaces as “open source has too many CVEs” or “we prefer vendor-supported software because it is more secure.”

The logic is: if we use closed source, we will not see vulnerability disclosures in our security feeds, and our risk dashboards will look cleaner. This is true. It is also delusional. The risk has not decreased. The visibility has decreased. You are managing your dashboard, not your attack surface.

This is the security equivalent of unplugging the smoke detector because the alarm is annoying. The fire does not care whether the alarm is on.

I have seen this play out in organizations where leadership mandated closed source alternatives to open source tools because the open source tools had “too many vulnerabilities.” The closed source alternatives had the same vulnerability classes; they just were not being publicly tracked. The organization’s risk posture did not improve. Its ability to detect and respond to supply chain issues actively worsened.

Package management: where the difference is concrete

The divergence between open source and closed source approaches to software distribution illustrates the broader point.

Linux distributions have used cryptographic package management for decades. When you run apt install or dnf install, the package manager:

1. Downloads the package from a repository
2. Verifies the package’s cryptographic signature against the distribution’s signing key
3. Checks the package hash against the repository metadata
4. Installs only if both checks pass

This is not optional. It is the default. Every package on a Debian, Fedora, or Arch system was built by a distribution maintainer from auditable source, signed with a key that the distribution controls, and verified on every install.

Windows has no equivalent system for most software. Installing applications on Windows typically means:

1. Download an .exe or .msi from a website
2. Hope the website is legitimate
3. Hope the download was not tampered with in transit
4. Run the installer with administrator privileges

Microsoft has made progress with winget and the Microsoft Store, but the ecosystem is still fundamentally built on trust-the-download. Most enterprise software is still distributed as installers downloaded from vendor websites with no automated integrity verification.

Chocolatey’s half-measure

Chocolatey (choco) tried to bring package management to Windows. It is a useful tool, but its architecture reveals the gap. Many Chocolatey packages, including high-profile ones like Google Chrome, do not host the binaries themselves. Instead, the package script points to the vendor’s latest installer URL.

The problem: the vendor can update the binary at that URL at any time. Chocolatey computes a hash when the package is created, but the file the URL points to changes without warning. When Google pushes a new Chrome installer, the hash in the Chocolatey package no longer matches, and installations break until someone updates the package.

This is not a niche edge case. It is the default behavior for many of the most popular Chocolatey packages. The package manager points to a URL it does not control, hosting a binary it did not build, with a hash that becomes stale without notice.

Compare this to a Linux distribution’s package management:

This is not a criticism of Chocolatey’s developers; they are working within the constraints of the Windows software ecosystem. It is an observation that the open source ecosystem solved this problem decades ago, and the closed source ecosystem still has not.

Warning

Supply chain integrity requires more than trust

The xz backdoor passed through a signed, official release tarball. Signatures proved authorship (Jia Tan), not intent. This is a real limitation. But the open source response, reproducible builds, multi-party release signing, reduced dependency depth, is only possible because the build process and source code are visible. Closed source vendors ask you to trust their build pipeline without the ability to verify it. You are trusting that their internal controls are better than the xz project’s were. Given that the xz project was a single maintainer with no corporate sponsor, that bar is not as high as it sounds.

The systemic conversation that only open source enables

After the xz backdoor, the open source community had a broad, public conversation about the systemic issues it exposed:

• Maintainer sustainability. Critical infrastructure maintained by unpaid volunteers is a systemic risk. The Linux Foundation, the Open Source Security Foundation, and corporate sponsors have increased funding for critical projects.
• Reproducible builds. If anyone can rebuild a package from source and get an identical binary, supply chain tampering becomes detectable. Debian, Arch, and others are actively working toward full reproducible builds.
• Multi-party release processes. Single-maintainer projects should not be the sole point of trust for release signing. Projects are adopting multi-party signing requirements.
• Dependency depth reduction. The xz backdoor worked because sshd indirectly depended on a compression library through libsystemd. Reducing unnecessary transitive dependencies reduces attack surface.

Closed source can still generate useful postmortems, vendor guidance, and third-party analysis. What it usually cannot provide is the same degree of public inspectability. In SolarWinds, the industry received important guidance from vendors, responders, and governments, but it did not get the same level of direct code and build-pipeline transparency that xz enabled.

When Crypto AG was exposed after 50 years, there was no remediation path. The affected governments could not audit the devices they had been using. They could not verify what had been compromised. They could only accept that everything encrypted with those devices should be assumed compromised, decades of communications, retroactively.

The open source ecosystem is not perfect. But it has a stronger built-in mechanism for public learning from failures and for independently verifying fixes. Closed source ecosystems can learn too, but they rely much more heavily on vendor-controlled disclosure.

The uncomfortable truth

Open source often has more publicly known vulnerabilities than comparable closed-source software. That is not automatically a sign of insecurity. In many cases it reflects the fact that more people can inspect the code, report flaws, and verify fixes. A high CVE count can indicate a healthy disclosure ecosystem as much as a weak product.

The alternative, fewer known vulnerabilities because fewer people can look, is not safer. It is less informed. And in security, less informed is less safe. Kerckhoffs understood this in 1883. The evidence from xz, SolarWinds, Juniper, and Crypto AG confirms it in 2026.

The xz backdoor was planted by a patient, skilled adversary who spent two years building trust. It was found by a curious developer who noticed a performance anomaly. The backdoor existed for five weeks. It was fully analyzed within days of discovery. Every affected system could verify its exposure and deploy a fix immediately.

The SolarWinds backdoor was planted by a different patient, skilled adversary inside a closed source company with corporate security controls. It ran for nine months. Many important details became public, but the incident was never inspectable in the same direct way as xz. Affected organizations depended heavily on the vendor, government alerts, and third-party responders to tell them what happened.

That is the comparison that matters. Not “open source has more CVEs.” Not “anyone can contribute to open source.” The comparison is: when the worst happens, which model finds it faster, understands it deeper, and fixes it more completely?

The answer is not close.