The xz-attack was a high profile supply chain attack that affected most systems and Linux based ones in particular.

Part of the attack involved replacing the maintainer of the xz utility through a coordinated harassment campaign and a trust building attack.
This was done quite expertly and the cyber security community has mostly pinned the blame of this nearly successful attack on lack of funding for critical open source projects.

In my eyes this's wrong on many levels
a. This completely ignores all the other technical and policy failures that nearly made this possible.
b. It focuses on the problem that is hardest to fix for technical people(socio-economic problems are for management an hr not engineers)
c. It proposes a solution that can't be implemented by the proposer.

I argue 16 different vulnerabilities were exploited, many of which can easily be solved on a technical level.

1. Maintainers have never been trained or enabled to spot malicious behavior or code or even been trained, to write secure code themselves. The best they can have is job experience with red teamers who shoot holes in their software.
Writing secure code isn't thought in schools, there're few tools to enable it and there're no courses available online to learn it. One can easily learn how to crack code, but that isn't the same.
2. Machine generated data is accepted. This puts unfair pressure on maintainers who've to review content machines instead of the work of a fellow human. All machine generated inputs should be replaced with scripts that generate the code.
3. Github has insufficient moderation to stop targeted harassment campaigns.
4. Nobody notes major maintainer changes as suspicious.
5. Tests can mod output binaries.
6. Nobody actually hash checks reproducable builds.
7. Regression tests are fully maintained by the same one that introduces regressions. For maintainability this doesn't matter for security it does.
8. git information isn't checked by anybody on accuracy(checking timestamps can simply be done when receiving pushes)
9. The control questions on key signing parties focus squarely on who you're, not what you claim to have done.
10. Code isn't written maintainable enough, backdoors can easily be patched out.
11. We accept hardcoded credentials in binaries.
12. SystemD does too many things as one program to the level that corrupting it allows one to transcend the principle of least privilege, since it does everything and thus also needs ever privilege.
13. Dynamic libraries can take over the calling library.
14. OSI layer 7 encryption can only be checked by the app. With session layer encryption(OSI 6) security tools could control your communications.
15. non-installer programs can change executables without external permission. Changing executables should be the exclusive right of the user, installer and package manager.
16. Trusted remote controllers are only known and checked by the remote control program not anybody else. This is risky enough there should be a second party to check this.
17. As the others have noted. Open source projects have insufficient tools, manpower and funds to maintain talent and/or run their own hr department.

Many of these issues can be solved with better tooling, or at least without needing to beg for money and manage KYC laws in a community that values anonymity and transparency.

1. Offer courses in writing code using security by design principles or simply teach developers to use existing security interfaces like pledge and landlock.
2. Tools to automatically generate scripts based on earlier and tools to detect and reject machine generated input should be made. Also this could be taken up in official guidance from the ssf, NIST or other influential organisation on security matters.
3. Duplicate issues should be forbidden and replaced by likes. Also microsoft should start moderating github like the social medium it's. The good news here is one can be pretty strict when moderating such a clearly themed forum as a github issue page.
4. Git fetch should warn for maintainer changes.
5. Change make to apply privilege minimization principles on the code base.
6. Distro maintainers should actually hash check their self compiled binary to the provided one. Automating this should make it more realistic that people do this.
7. Make a tool that generates automatic regression tests based on older versions of the program.
8. Real time git recipients like maintainers and hosting providers should check at least the time with the here and now.
9. Make a tool that generates based on your git history questions like: "why did you use popen for commit #12"
10. More maintainability tooling and checks.
11. Distros and/or virusscanners should detect and block code with key size high entropic blocks of data.
12. Splits SystemD in several seperate sandboxes(the SystemD team seems to have actually realised the first part of this)
13. Patch the library loader.
14. Make an OSI 6 encrypted connection interface in the OS and encourage its usage for high risk applications.
15. Simply don't give programs the permission to write any file for which anyone except root has execution permissions.
16. Have a central "remote control trusted keys" database and request control through an api that checks it against these keys(this api should be simple and just run a by you provided binary with root permissions, when the authentication succeeds).
17. Moneyyy or ... independent press outputs. The problem here's that one person was, so unaccountable that when they dissapeared and somebody else took their place nobody even noticed. Let a bunch of guys scour the internet for major, but non-critical security events like critical maintainer changes, large code base changes, unreadable parts of code bases and document them.

If you made it so far.
Thank you for listening to my rant.
If you have your own insights feel free to provide them.

Last edited by LoudTechie on 30 Apr 2026 at 11:40 pm UTC