In 2018, Saudi journalist Jamal Khashoggi's fiancée's phone was hacked. Later that year, Khashoggi walked into the Saudi Arabian consulate in Istanbul to obtain documents related to his planned marriage, and left two hours later in a body bag.1
It's easy to forget that the work we do affects real people. It's easy to feel, if only unconsciously, that the point of the Rust language is to be mathematically beautiful or fun to use. It's easy to forget that buffer overflows aren't just bad in the abstract, but that sometimes, they get real people killed.
And it's about to get much, much worse.
In my day job, I work on a security team, so I have access to hard data and water cooler talk with colleagues at Google and elsewhere about agentic bug-finding models, which are behind what the security industry has coined the "vulnpocalypse". For the past few weeks, I've been repeatedly asked the same question: "Mythos. Is it really that bad?" In a word: Yes.
The point of this post isn't to adjudicate this claim, so in leiu of a serious argument, I'll just leave you with this graph courtesy of Firefox:
Many factors will determine the long-term equillibrium of vulnerability discovery,2 but that equillibrium will take many years to reach. Regardless of how that plays out in the long term, the medium term impact is clear: memory-unsafe3 open-source4 software is not ready for high-quality bug-finding agents to be made widely available. It is expected that broad availability will happen at some point this summer,5 and when it does, few open source programs written in memory-unsafe languages will be safe from catastrophic exploits. Many actors will use these exploits to steal identities, or steal money, or commit other run-of-the-mill cyber crimes. But some will use these exploits to kill people.6 I am not being hyperbolic when I say that when these agents are made available, more people will die.
While memory safe languages are not a panacea, they will prevent the majority of these vulnerabilities (a typical estimate is 70%), and they will prevent the highest-impact of these vulnerabilities.7 This makes switching to memory safe languages a moral imperative. Alternatives such as Carbon are being developed, and other languages with different performance characteristics like Go or Java exist. However, when it comes to memory safe languages which are already in production and which impose no overhead relative to C or C++,8 Rust is the only option. Therefore, it is a moral imperative: Rust must succeed.
I am honored to call many people in the Rust community some of my closest friends. I have heard their stories at conferences, and over drinks, and on Zulip threads and Jitsi meetings. We have come to Rust for many different reasons (although they usually involve some form of nerd sniping). While the community has had its struggles, as any open source community does, it has always been an absolute blast – in our better moments, we have been kind to each other and written amazing software. To paraphrase Scott McNealy, we have "kicked butt, had fun, and changed computing forever."
I don't see why we can't keep having fun with Rust for the rest of our lives. But at the same time, we must acknowledge a hard truth: of the billions of people our software touches, only a tiny fraction know what a pointer is. To these people, it's irrelevant whether Rust is beautiful or fun. But for some of these people, if Rust doesn't succeed, they will die.
My dad and sister are both doctors, and I've always admired how they show up to work every day and face the weight of real, life-and-death consequences. The connection between their work and the lives of real people is immediate. One contrast that I've seen between their industry and our own is how they measure what is important.
Imagine that your parent had a worrisome lump on an annual physical and went to the radiologist to get it checked out. Imagine that the radiologist could choose a highly-accurate imaging technology, but instead they chose one with a high false-negative rate. You would be furious that this radiologist was jeopardizing your parent's life, and it wouldn't make you feel any better if the radiologist tried to reassure you that the technology they chose used a cleverer design, or had a better user interface, or made them feel nostalgic for when they were in med school. The radiologist's job is to treat your parent, and everything else is secondary.
Whatever the reason we each got into Rust, and whatever keeps us going, we have a new responsibility that most of us never asked for: people are now depending on us for their survival. They depend on Rust being secure. But more importantly, since Rust is already the most secure systems language in existence, they depend on Rust succeeding.
I wrote this post as a celebration that we have built a language so secure that people's lives depend on projects choosing it. We should be immensely proud of what we've accomplished.
But I also wrote it as a call to arms. Now more than ever, it is important that Rust succeed. In the coming months and years, we will need to make hard choices. We cannot be all things to all people. We will need to prioritize some use cases over others. We must think of progress and consensus as virtues in and of themselves. We must learn to recognize when having a consensus is more important than having the right consensus, and in these cases, to pick progress over stagnation. Whether it's C++ interop, or auditability, or any other un-glamorous feature which will nonetheless increase Rust adoption, we will have to hold our noses, wade into the muck, and get the work done.
I want to keep having fun, and thinking deep thoughts, and writing great code. I don't want to give up what has made Rust a joy to participate in.
But I also don't want people to die. If that means having a little less fun and being a little more serious, then I believe in our community's ability to rise to the occasion.
The exact chain of events is complicated, with the intelligence services of multiple countries targeting multiple people close to Khashoggi for surveillance, both before and after his murder. Publicly-available information is insufficient to prove that Khashoggi would not have been murdered had certain hacking attempts been unsuccessful. However, many other examples, such as the ransomware attack against Synnovis in 2024 and the WannaCry malware in 2017, demonstrate that hacking often leads directly or indirectly to the deaths of innocent people.
If you had asked someone in 1995, "what will be the long-term social consequences of the proliferation of cellular phones," nobody would have answered, "we will see a rapid rise in the suicide rate among teen girls." Anyone who tells you they know how this will play out is wrong (or lying).
To be less glib, some people have argued that the long-term effect of high-quality bug-finding agents will be to make software more secure, as teams will use them to catch potential vulnerabilities before they are merged. This is a real possibility, but so is the opposite, and in any case it may take a long time reach any equillibrium. The point of this article isn't to argue that we can predict any particular outcome, but rather that we have to consider that catastrophic outcomes are sufficiently probable to be worth worrying about and preparing for.
While memory safe languages are not free from vulnerabilities, they are generally free from memory safety vulnerabilities. Non-memory safety vulnerabilities tend to permit exploits which are significantly less impactful than the exploits permitted by their memory safety-related counterparts.
Some have suggested that agents are good enough at binary analysis that even closed-source software won't be safe – as long as an agent can inspect the binary, it can find vulnerabilities.
Specifically, it is expected that Mythos itself or equivalently powerful models will become available for public use, possibly with some guardrails, but likely guardrails that will be easy for serious actors to bypass.
More accurately, they will use these exploits to steal information which will allow them to kill people.
Memory safety vulnerabilities disproportionately represent our most severe vulnerabilities. In 2022, despite only representing 36% of vulnerabilities in the security bulletin, memory-safety vulnerabilities accounted for 86% of our critical severity security vulnerabilities, our highest rating, and 89% of our remotely exploitable vulnerabilities. Over the past few years, memory safety vulnerabilities have accounted for 78% of confirmed exploited “in-the-wild” vulnerabilities on Android devices.
...which is a non-negotiable for many teams when switching languages.