With great power should come greater responsibility
The modern "tech industry" (let's combine hardware and software here, because basically all of my issues apply to both; this may at times be left as an exercise to the reader, but you're a smart cookie, you'll figure it out) is in a pretty unprecedented position. Billions of people use our products every day, and they place in it an incredible amount of trust, and we process an incredible amount of intimate and sensitive data. At the same time, people broadly don't understand how any of these systems actually work.
As far as consumer-facing technologies are concerned, we broadly operate without informed consent, and as a result, we need to be incredibly responsible in how we operate at all levels. People largely can't go anywhere else for the digital services that run the modern world, and it's very difficult to operate in 2026 without essentially trusting that technology you don't understand will work as it should.
We have also broadly betrayed this trust, both for the sake of cost-cutting, and because many of the people in our industry don't understand the position we're in, and the responsibility with which we need to approach building our products, at the moment.
Case study 1: Rust in Linux
Take for instance some of the recent controversies around Rust code being added to the Linux kernel. I don't think it's too controversial to say that C and C++ are not languages that are well-suited to writing high-reliability software. Not that I'm saying it's impossible to write good C and C++ code - just ask NASA - but you can write bad code in C++ that other languages simply won't let you write.
Chromium has said that 70% of their issues are the kinds of memory vulnerabilities that Rust (and not specifically Rust here - I don't really care what memory safe language people pick) would generally eliminate. Of course, the Linux codebase is very different to Chromium, but I think we can safely say that, if we had a magic button that converted the Linux kernel's source to [INSERT LANGUAGE IN WHICH YOU CANNOT SHOOT YOURSELF IN THE FOOT], it would have a reduced number of vulnerabilities, and that this would be a Very Good Thing.
However, we've had a lot of problems with this migration. People refuse to let Rust integrate with their code because they don't like the syntax, or it's not what they're used to, or because they find Rust developers annoying (personally, as someone who writes Rust sometimes, I'm happy to admit that I'm a reasonably annoying guy, so fair enough on that point).
Quite frankly, none of these reasons are valid. The Linux kernel is deployed on billions of hardware devices that process banking information, people's nudes, everything. We trust the Linux kernel and systems built on top of it to manage information that can be used to kill people. We need, therefore, to take any option that improves its secu.
The issues with the kernel also, of course, dovetail with some of the other issues inherent to using the current open-source ecosystem "in production". I'd like to say at the outset that I absolutely love open-source software. I think it's a fantastic way of making things open to anyone, and I'm writing this on a computer that's run pretty much only Linux for the last 2 years. However, we know, and we've seen exploited at scale, massive problems with the way we deploy modern systems.
Case study 2: XZ (and other backdoors)
I'm not the first person by any means to observe this, but the above is basically exactly what happened with the XZ backdoor. We were incredibly close to having a backdoor, possibly designed and therefore usable by the Russian government so far as anyone can tell, in a majority of the systems that are currently deployed. It's entirely plausible that there may be other backdoors in the open-source ecosystem we don't yet know about, and we can't do much, or haven't done much, to stop this happening again. We trust individual people to build and maintain critical infrastructure, and these people are flawed. Maybe someone gets radicalised and decides to build a backdoor themselves, maybe they don't quite understand a pull request they approve, maybe they just get tired and hand their project over to a malicious actor because they're just a person and, like the rest of us, they're flawed (as happened with XZ).
The metaphorical centre cannot hold. Open-source systems, as they currently exist, shouldn't be used in production. So where's the solution?
Well, allow me for a minute to yap about the European Union.
The Cyber Resilience Act, as flawed as it is, requires that a bill of materials be published for many software products, and requires certain things regarding notification and fixing of vulnerabilities. This is a good first step, but ideally, in the future, we will need to move towards these projects being formally audited and certified, and having real procedures in place for ensuring that projects are funded and maintained, and that people/companies are liable for vulnerabilities in the work that they maintain.
I'm not suggesting that someone be legally liable for some hobby project. I have lots of code I've written that I shouldn't have to legally be responsible for, but with that benefit comes the understanding that my code shouldn't be used in critical systems. I'm happy with that trade-off, but we need this to become the standard across the industry.
If a system is deployed commercially or to handle sensitive data, every part of it should have a guarantor of security. That could be an open-source foundation, an external contractor, or the company that ships the system (by forking the dependency in-house), but we need a documented and universal system for making sure that issues get fixed and that someone can be held accountable when something goes wrong.
Doing it right
This is going to be a slightly more speculative section. I'm keenly aware that I'm not particularly skilled technically compared to many people, so I'll try to stick to the loosest level of detail to get my point across while hopefully not sounding like too much of an idiot.
The best and only way to do security is by design rather than by implementation - we've been trying the implementation route up until now, and, quite frankly, if it had worked, I wouldn't be writing this, now would I? We can't rely on people to "just write good code" because that doesn't scale. We're increasingly just chucking stuff into Claude, and at that point the quality of the code certainly can't be guaranteed at scale. As a result, the only solution is to build systems that cannot fail by design, or that fail in such a way that damage is minimal and/or isolated to places where it doesn't much matter.
In the past, software's primary bottleneck was performance, and compute was at enough of a premium that hand-crafted assembler and C were the only ways to write performant software. With all due respect to the wizards who were able to build huge projects like this, we don't have these limitations any more.
At the scale of the personal computer, we essentially have all the compute we could ever need, and, at a server scale, the fact that most of our current large-scale systems have been running for upwards of 10 years indicates that migrating to safer designs is entirely doable from a compute standpoint.
Conclusion
So... yeah, not a great state of affairs at the moment.
If nothing else, I think the most important conclusion to draw from all this isn't technical, but just to acknowledge the faith people have in us to do our jobs right and the responsibilities we have as a result. At the moment, we build systems without, in my opinion, giving this enough weight, and that's going to need to change in the near future.
The unfortunate thing is that fixing this is probably going to be extremely expensive and take quite a while. Technical debt tends to be like that. For that reason, it's probably not going to happen until there's some absolutely massive compromise of some critical system that breaks public trust entirely and forces regulation. But hey, if you build things, it's entirely possible to build them well right now, and from there hopefully it'll just be a matter of ensuring that it spreads. I'll leave the implementation of that as an exercise to the reader who has some mixture of technical and regulatory knowledge/influence instead of the over-caffeinated, sleep-deprived 20 year old writing this at the moment.
I'd like to give some credit here to the fine people at TechWorks and the IoT Security Foundation for putting on their conference in London last week. Talking to the people in the industry who are on the front lines of all this has helped me tremendously to see the issues, put that into words, and hopefully have some ideas about the most basic, most general ways we can start to fix them (and my ideas really are the most basic possible!). There's a lot of fantastic people working on this issue Right Now; maybe you and I should join them.
Alex Hegedus-Adkin