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 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 patched the RSA key decryption path in liblzma in a way that would have allowed remote code execution via sshd on systems 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 noticed the CPU anomaly. It was extraordinarily close.
What "Supply Chain Attack" Actually Means
A supply chain attack targets not the software you are using directly, but something that software depends on — 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 via social engineering (as in XZ) or by compromising a maintainer account directly.
- Package registry injection: Malicious packages published to npm, PyPI, or RubyGems via typosquatting, or legitimate package names hijacked when maintainers abandon them.
- Build system compromise: The infrastructure that builds and signs releases is compromised, allowing injection of malicious code into legitimate source. SolarWinds SUNBURST worked this way — the Orion build pipeline was compromised and signed malicious updates distributed to customers.
- CDN or distribution compromise: The Polyfill.io incident in 2024 — a widely-used CDN serving JavaScript polyfills was acquired and began injecting malicious code into responses for certain users.
Reading source code on GitHub tells you what the developers intended to ship. It does not tell you what is 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 designed to protect high-value targets — dissidents, journalists, lawyers, activists — which makes it a priority for sophisticated adversaries including nation-state actors.
A modern encryption application depends on cryptographic libraries (OpenSSL, libsodium), compression libraries (zlib, liblzma), networking stacks, build tools, package managers and their dependency trees, and CI/CD systems that build and sign releases. Each of these is a potential entry point.
The 2018 event-stream npm incident illustrated this: a popular Node.js library was transferred to a new maintainer who injected code targeting the Copay Bitcoin wallet — a targeted attack buried in a dependency chain most users never examine.
Reproducible Builds: The Strongest Available Mitigation
Reproducible builds make the build process 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 is being distributed actually matches the published source.
Tor Browser and Debian have invested heavily in reproducible builds. Signal's desktop client has moved to reproducible builds as well. When reproducible builds are in place, a compromised build server cannot silently alter what gets distributed — independent rebuilds would produce a different hash, and the discrepancy would be detectable.
Reproducible builds do not prevent supply chain attacks. They make them detectable — which is a meaningful difference.
— Reproducible Builds project documentation
Code Signing, Sigstore, and the Package Verification Landscape
Code signing is a baseline protection against tampered distribution packages. What it cannot tell you is whether the maintainer who signed the release had already been compromised.
Sigstore, supported by the OpenSSF with contributions from Google and Red Hat, uses short-lived certificates tied to an identity provider 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.
What Users Can Realistically Do
| Action | Protects Against | Difficulty |
|---|---|---|
| Verify release signatures | Tampered distribution packages | Low |
| Pin dependency versions | Automatic ingestion of malicious updates | Low–Moderate |
| Use software with reproducible builds | Compromised build infrastructure | Low |
| Prefer software with fewer dependencies | Smaller attack surface | Moderate |
The Human Element Is the Hardest Problem
The XZ attack worked because it exploited the social dynamics of open-source maintenance. The attacker did not break any cryptography. They built trust over two years, identified a maintainer under stress, and patiently waited to introduce malicious code that looked like a routine build improvement.
Open-source projects run on the goodwill of unpaid, underfunded, chronically time-poor maintainers. This is not a technical problem with a technical solution. Some projects are responding with stricter controls on build script modifications, multi-person approval requirements for security-critical code paths, and formal threat modeling that treats maintainer accounts as a potential attack surface.
What This Means for Evaluating Privacy Software
When choosing a privacy-focused application, 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?
Open-source is still meaningfully more auditable than proprietary software. But "the code is public" does not mean "the code you are running has been audited." Those are different claims, and the gap between them is exactly where supply chain attacks operate.
Originally published at havenmessenger.com
Top comments (0)