On March 29, 2024, Andres Freund — a Microsoft engineer and PostgreSQL contributor — noticed something odd while investigating unexplained CPU usage in SSH on a Debian testing build. liblzma, the compression library bundled with XZ Utils, was performing extra work it had no business doing. After careful analysis, Freund had found what turned out to be one of the most sophisticated software supply chain attacks ever discovered in the open-source ecosystem.
The attacker, operating under the pseudonym "Jia Tan," had spent roughly two years earning maintainer trust on the XZ Utils project. They submitted legitimate bug fixes, took on maintenance duties, and eventually introduced a carefully hidden backdoor — CVE-2024-3094 — into the build system scripts. The payload, once extracted, patched the RSA key decryption code path in liblzma in a way that would have allowed an attacker with a specific private key to execute arbitrary code via sshd on any system where systemd had linked against the compromised library.
The only reason this attack was caught before widespread deployment is that Freund was running a pre-release Debian version and happened to notice the CPU anomaly. On stable Linux distributions, the malicious version had not yet propagated. It was extraordinarily close.
What "Supply Chain Attack" Actually Means
A supply chain attack targets not the software you're using directly, but something that software depends on. The goal is to compromise the production or distribution process — the chain between source code and the binary running on your machine. There are several distinct categories:
- Maintainer compromise: An attacker gains commit access to an upstream project, either by social engineering (as in XZ) or by compromising a maintainer's account directly.
- Package registry injection: Malicious packages are published to npm, PyPI, or RubyGems with names similar to popular packages (typosquatting), or legitimate package names are hijacked when maintainers abandon them.
- Build system compromise: The infrastructure that builds and signs releases is compromised, allowing the attacker to inject malicious code into otherwise legitimate source. This is what SolarWinds was: the Orion build pipeline was compromised, and signed malicious updates were distributed to customers.
- CDN or distribution compromise: The Polyfill.io incident in 2024 — a widely-used CDN serving JavaScript polyfills was acquired by a Chinese company and began injecting malicious code into responses for users from specific countries.
Reading source code on GitHub tells you what the developers intended to ship. It does not tell you what's actually running on your machine. The gap between those two things is where supply chain attacks live.
Why Privacy Tools Are Particularly Valuable Targets
Compromising a video game is embarrassing. Compromising Signal, a PGP key management tool, or a VPN client is strategically valuable. Privacy software is specifically designed to protect high-value targets — dissidents, journalists, lawyers, activists — which makes it a priority for sophisticated adversaries including nation-state actors.
The attack surface is larger than it looks. A modern encryption application doesn't just depend on its own code; it depends on:
- Cryptographic libraries (OpenSSL, libsodium, BoringSSL)
- Compression libraries (zlib, bzip2, liblzma)
- Networking stacks
- Build tools (compilers, linkers, build scripts)
- Package managers and their dependency trees
- CI/CD systems that build and sign releases
Each of these is a potential entry point. The 2018 event-stream npm incident illustrated this at the package-manager level: a popular Node.js library had been transferred to a new maintainer who injected code targeting users of the Copay Bitcoin wallet — a small, targeted attack buried in a dependency chain most users never examine.
Reproducible Builds: The Strongest Available Mitigation
Reproducible builds are a technique where the build process is made deterministic: given the same source code, build environment, and tools, the output binary is bit-for-bit identical no matter who runs it or when. This allows independent parties to verify that what's being distributed actually matches the published source.
Tor Browser and Debian have invested heavily in reproducible builds. Signal's desktop client moved to reproducible builds as well. When reproducible builds are in place, a compromised build server can no longer silently alter what gets distributed — independent rebuilds would produce a different hash, and the discrepancy would be detectable.
Reproducible builds don't prevent supply chain attacks. They make them detectable — which is a meaningful difference. — Reproducible Builds project documentation
The limitation: verifying reproducibility requires someone to actually rebuild and compare. For popular software, community members do this. For smaller projects, it may never happen.
Code Signing, Sigstore, and the Package Verification Landscape
Code signing — where a developer cryptographically signs their release artifacts — is a baseline protection. If a package is signed and the signature verifies against a known-good key, you can be confident the package hasn't been tampered with in transit. What it can't tell you is whether the maintainer who signed it had already been compromised.
Sigstore, a project supported by the OpenSSF (Open Source Security Foundation) and contributions from Google, Red Hat, and others, takes a different approach. Instead of relying on long-lived private keys that maintainers must protect indefinitely, Sigstore uses short-lived certificates tied to an identity provider (GitHub, Google, etc.) and appends signatures to a public, append-only transparency log (Rekor). This makes it possible to audit the entire history of what was signed, by whom, and when.
The npm ecosystem began integrating Sigstore-based provenance attestations in 2023. PyPI has similar initiatives in progress. The gap right now is adoption: the infrastructure exists but relatively few packages use it consistently.
What Users Can Realistically Do
| Action | What it protects against | Practical difficulty |
|---|---|---|
| Verify release signatures | Tampered distribution packages | Low — most major projects publish PGP or Sigstore signatures |
| Pin dependency versions | Automatic ingestion of malicious updates | Low for personal use; moderate for teams |
| Use software with reproducible builds | Compromised build infrastructure | Low — just check if the project has it |
| Run on minimal, locked systems | Reduces blast radius of a compromised package | Moderate — requires discipline about software installation |
| Prefer software with fewer dependencies | Smaller attack surface in the dependency graph | Moderate — requires evaluating alternatives |
The Human Element Is the Hardest Problem
The XZ attack worked primarily because it exploited the social dynamics of open-source maintenance. The attacker didn't break any cryptography. They built trust over two years, identified a maintainer under stress, and patiently waited for the moment to introduce malicious code that looked like a routine build improvement.
Open-source projects often run on the goodwill of a small number of maintainers who are unpaid, underfunded, and chronically time-poor. When a new contributor appears offering to help with the maintenance burden, declining feels ungrateful. Security-conscious contributors who review every commit carefully are in the minority. This is not a technical problem with a technical solution.
Some projects are responding with stricter controls on what contributors can modify in build scripts, multi-person approval requirements for changes to security-critical code paths, and formal threat modeling that treats maintainer accounts as a potential attack surface. These are good steps. They are also expensive to maintain for volunteer projects.
What This Means for Evaluating Privacy Software
When you choose a privacy-focused application — an encrypted messenger, a VPN client, a PGP tool — the questions worth asking go beyond "is the protocol sound?" to include:
- Does the project publish signed releases? Do you verify them?
- Are builds reproducible and independently verified?
- How many people have commit access to the main codebase and its critical dependencies?
- Is the dependency tree auditable and pinned?
- Is the build infrastructure itself protected (hardware keys for CI signing, isolated build environments)?
For Haven, we use signed releases, pinned dependency versions, and isolated build environments. Our cryptographic core is in a Rust/WASM library with a minimal dependency footprint — fewer dependencies means a smaller surface for this class of attack. We're not immune to supply chain risk (no software is), but we try to make the attack surface explicit and as small as possible.
The broader takeaway: open-source is still meaningfully more auditable than proprietary software. But "the code is public" does not mean "the code you're running has been audited." Those are different claims, and the gap between them is exactly where supply chain attacks operate. See also our post on what end-to-end encryption actually protects — the cryptographic layer being sound doesn't help if the application delivering it has been tampered with at the distribution layer.