The xz backdoor: open source supply chain security is a topic for architects, not lawyers

At the end of March 2024, security researcher Andres Freund discovered that xz utils - a compression library present in the majority of Linux distributions - had been deliberately backdoored. This was not an accidental vulnerability. It was a multi-year, carefully planned operation: an attacker operating under the alias Jia Tan spent two years behaving as a conscientious contributor, earned the community's trust, gained release publishing rights - and in the final step embedded malicious code.

The backdoor was caught before it reached stable releases in most major distributions. Large-scale damage was avoided. But this incident is a textbook example for discussing how security works in the world of open source dependencies.

Why this is not a story about "someone got hacked"

The classic model of a cyberattack is an adversary finding a vulnerability and exploiting it. This was different: the attacker became part of the software production system itself. They did not attack from outside - they were inside, with legitimate rights.

This is called a supply chain attack. The target is not the final product but what it is assembled from. Inserting malicious code into a dependency used by thousands of other projects is more effective than attacking each of them individually.

For a business this means: even if your own team writes clean code - your software is built from dozens or hundreds of components written by other people. And that is an attack surface.

What this means for architects, not for lawyers

When incidents like this happen, the first reaction of many companies is to ask the IT department for a "risk assessment" or to ask legal whether anything needs to be done about licence agreements. That is the wrong level of response.

The questions that belong at the architectural level:

First - do we know what is actually running in our systems? This is called an SBOM - a software bill of materials. Most companies do not have an up-to-date SBOM even for their critical systems.

Second - how quickly can we update a specific dependency everywhere it is used? When a vulnerability is discovered, the speed of the update is critical. If the answer is "a few weeks" - that is an architectural problem, not an operational one.

Third - how do we learn about new vulnerabilities in our dependencies? This should be an automated process, not "we heard from a colleague at another company."

The false security of "we only use well-known libraries"

A common answer: "this does not affect us, we only use well-known libraries from major organisations." xz utils is exactly that kind of library. It is part of Red Hat, Debian, Ubuntu, and openSUSE. Well-known, long-established, with a history.

Supply chain attacks target precisely these components - the ones trusted by default.

Practical measures worth considering

This is not a call to rebuild everything immediately. It is a call to have a conscious approach:

1. Do we have an inventory of the key open source dependencies for our critical systems?
2. Are we subscribed to vulnerability notifications (CVE) for our key dependencies?
3. What is our process for emergency-updating a dependency?
4. Do we verify package integrity at install time?
5. Do we have isolation between systems so that a compromised dependency does not give access to everything?

The xz utils incident is not a reason for panic. It is a reason to ask: how well do we understand what our software stack is made of?