The XZ Backdoor and Beyond: A Call for Enterprise Investment in Open-Source

The XZ Backdoor and Beyond: A Call for Enterprise Investment in Open-Source

The task of assessing the trustworthiness of open-source (OSS) that is in use, or that is being considered for use, is more complex for OSS than for proprietary software, because there is, generally speaking, no direct relationship between the authors of software and those who use that software.”—Aeva Black, Section Chief, Open-Source Software Security at CISA.

I have long observed that companies reliant on open-source software—which today includes nearly all of you—neglect their investment in open-source security processes. These processes must include continual engagement with information about project changes and internal accountability. Advocating for intentional project participation and corporate accountability measures should be paired with vigilant remediation of open-source dependencies. Together, these efforts ensure we manage and communicate security issues inside open-source projects and our companies in the best way possible, in line with industry best practices and embargoes. 

Vulnerabilities of Under-Resourced Open-Source Projects

In addressing enterprises’ responsibilities within the open-source software landscape, I advocate for a pragmatic approach grounded in real-world experiences. Know what your dependencies are, remain informed about those projects, and ensure the software’s maintainers are well-resourced (or you are willing to take on that effort). Recent security incidents, such as the notable XZ backdoor, illustrate the vulnerabilities of under-resourced projects to social engineering tactics, particularly when disguised as assistance. Many popular projects, often operated by just a handful of maintainers, strive to meet the extensive demands of commercially used software. Unfortunately, we frequently observe predictable outcomes from such scenarios.

The XZ backdoor example highlights the critical need for sustained investment by open-source consumers—like your $software_company1—in proper governance and shared responsibility across your extensive open-source project dependencies.

Note: The XZ exploit, identified as CVE-2024-3094, involved a sophisticated backdoor inserted into the XZ Utils compression library by a maintainer under the guise of “Jia Tan.” They added this backdoor intricately to the build process rather than the source code, complicating detection. It exploited the `IFUNC` mechanism of `glibc` to manipulate SSH authentication, impacting several Linux distributions. The exploit underscores critical vulnerabilities in the open-source software supply chain, highlighting the importance of rigorous security practices.

Catalog Your Dependencies and Their Security Changes

The first pressing issue in enterprise open-source strategies is managing dependencies and their security changes. Currently, enterprises struggle to track both internally developed dependencies and those sourced from open-source. Unfortunately, there are no simple solutions to this problem.

A critical security responsibility is thoroughly understanding the open-source components used within any custom software and any tooling used to produce it. Next, you need to remediate issues across your installation base. Monitor open-source security mailing lists and other resources, like the Common Vulnerability and Exploit (CVE) database, to stay informed about impactful vulnerabilities. This knowledge lets you promptly identify and update affected components ahead of and during a security incident.

You may even maintain a catalog of dependencies already. Traditionally, organizations have cataloged licenses for compliance. Expanding that practice from compliance to awareness of and engagement with those dependencies is important, enhancing security oversight.

You must actively participate in open-source projects on which your software relies. Understanding these projects’ ongoing changes and security measures is vital for your success. For instance, major tech companies like Google, Microsoft, and Amazon each actively engage in the Kubernetes community to support their products, GKE, Azure AKS, and Amazon EKS, respectively. Their ongoing and project-level involvement helps them stay abreast of security developments and contribute to collective safety efforts.

Onwards and Upwards, Open-Source Security, Here We Go

Security in open-source software continues to be an unattended problem we ignore—even though it’s certainly on our government’s radar. Honestly, we need to care more, too. 
To wrap up, I recommend reading the following article that dives into this topic: “Continued Progress Towards a Secure Open-Source Ecosystem,” by Aeva Black, who heads up Open-Source Software Security at CISA. It’s a great resource to learn more about what’s being done to safeguard our digital security infrastructure as a nation.

  1.  I still have a soft spot for Perl. ↩︎

By:


Leave a Reply

Discover more from hi, i'm sarah

Subscribe now to keep reading and get access to the full archive.

Continue reading