Open source is not automatically safe because the code being open means anyone can inspect it, not that anyone has. The xz incident in 2024 showed a backdoor sitting in release tarballs that a wider audience might never have reviewed. It was found by chance, not by process.
What happened, briefly
On 29 March 2024, Andres Freund posted to the oss-security list that he had traced odd behaviour on Debian sid systems, including slow SSH logins and high CPU use, to a backdoor in the xz 5.6.0 and 5.6.1 release tarballs. He wrote that he was not a security researcher or reverse engineer. The malicious build script was in the tarball but not in the git source, and the payload was hidden in test files.
CISA's alert the same day recommended downgrading to an uncompromised version such as 5.4.6, hunting for malicious activity, and reporting findings.
What the incident does not show
It does not show that open source is worse than closed source. We do not know what is hiding in code we cannot read. It also does not show that open review failed in a dramatic way: the backdoor was caught within weeks of the affected releases, and mostly before wide distribution in stable systems, according to the disclosure.
What it does show
- The artifact you install can differ from the source you read. Here the tarball held a script that git did not.
- Trust in a maintainer is a security control, and it can be gamed over time.
- Small, widely used libraries can have very few people behind them.
- Detection was luck plus one curious engineer, which is not a repeatable control.
Controls that address those lessons
- Build from source in a pipeline you control, and compare to published tarballs where practical.
- Check project health. OpenSSF Scorecard automates checks such as code review, branch protection, signed releases and contributor diversity across organizations, which speaks directly to single maintainer risk.
- Delay adoption of brand new releases of critical low level libraries by a short, set period, unless a fix is urgent.
- Keep an inventory so you can answer where a package runs within hours.
- Monitor for behaviour change, such as new network calls from build or login paths.
A fair summary
Open source gives you the ability to verify. Verification still takes someone's time and a process to do it. If nobody on your side owns that, you are relying on strangers and luck.
Safeguard covers the inventory and prioritisation parts of this with SBOM and dependency scanning and reachability analysis, and you can try a free scan at gold.safeguard.sh/scan. Autonomous remediation with fix PRs is off by default, and every category starts on Manual, so a person approves changes.
Quick check
Would a vulnerability scanner have caught the xz backdoor before disclosure?
No. A scanner matches components against published advisories, and no advisory existed until the backdoor was found and disclosed.
Should teams stop using open source?
No. The sensible response is inventory, build verification and health checks on critical dependencies.
Sources
- Andres Freund, oss-security disclosure, 29 March 2024
- CISA alert on XZ Utils, CVE-2024-3094
- OpenSSF Scorecard
Last reviewed: 19 October 2026.
