The Atlantic‘s Charlie Warzel interviews AI-cybersecurity professional Alex Stamos, who argues, “The Internet Might Need to Be Rebuilt From Scratch.”

Warzel’s setup:

The digital infrastructure that powers our entire on- and offline lives is, according to the people who protect it, more vulnerable than ever. The internet as we know it is a very fragile ecosystem. So much of it is built off of code that’s written by humans—that is, by nature, full of flaws or bugs. Some of our critical digital infrastructure, it’s built off of decades-old technology that’s running on ancient code languages.

The internet is a marvel. But it is also, like any massive human endeavor, imperfect and full of vulnerabilities. One way to look at the history of cybersecurity is as a race between people who are looking to exploit all those vulnerabilities and the people who can fortify our systems and keep them secure.

But in recent months, AI has threatened to change the dynamics of that race. AI agents—which are cheap, relentless, and highly capable hacker armies—are proving excellent at finding vulnerabilities in code. Sometimes, oftentimes, in places that humans had never thought to look. And the result has been this series of high-profile cybersecurity incidents, each one adding to this feeling that we’ve entered a new era.

I was aware of the huge PHP exploit, since OTB runs on WordPress, which in turn depends on PHP. But I didn’t realize how far beyond that it went.

Stamos describes it this way:

[A]ttackers are getting the benefit from AI, where they have the ability to use AI to automate what we call kill chains. So you know, this is a term we have stolen from the military—where, when the military says “kill chain,” they mean to actually kill something. In the cyber world, those are the steps you take to break into a network and to do something.

And traditionally, you could automate some parts of a kill chain. But there’s often human steps. And just in the last several months, we’ve gotten to the point of where AI models—and especially the open-weight models, the models that you can run locally on hardware you run yourself, and even commodity hardware like these new Mac Studios that you can buy—are good enough that basically every step of the kill chain can be completely automated with AI. And so that has really changed the game here—where you can get rid of any human bottleneck. And that has completely changed the economics and the speed at which attackers can move.

[…]

There’s a good thing happening, which is—these vulnerabilities have existed for decades, right? We have, you know, years and years and years of human-written code that is not reliable, that is not safe. That is often written in languages that are not what we call memory safe and type safe, that are written in computer languages that were not fundamentally easy to write safe code in. Languages like C and C++.

And unfortunately, it turns out that human beings writing code in those languages—it’s very hard to make systems that are safe in the presence of these superhuman bug-finders. And so what’s happening is we are now burning through all of these bugs that were written over two decades, and they are being found and discovered and patched. But the problem is, once those patches are released, actually getting them fixed in the wild takes a while. And so bad guys have a window during which they can then exploit them. And over the last year, we have seen that exploitation happening. Sometimes manually, and more and more automatically.

There are multiple problems at work, with the main one simply being that most of us end users aren’t technology experts. The site redesign over the summer was the first time I truly learned how to use the Gutenberg backend that WordPress rolled out way back in 2018. And I still have only a vague idea of what PHP is and next to no understanding of how to use it. On my previous server, it often went months, if not years, without getting patched. Thankfully, I’ve now outsourced that work to the WordPress folks, who not only have the in-house expertise I lack but also have rather strong incentives to keep everything up to date.

Regardless, Stamos argues,

I think what we’re gonna have to do is we’re gonna have to rewrite a bunch of code.

[…]

Every time one of these new models comes out, we still have a huge number of incredibly complex memory-management flaws. And so I think for these really complex code bases, we’re going to have to refactor them. We’re going to have to rebuild them in languages like Rust, where you have the ability to, one, there’s entire classes of bugs they don’t have. And then you also have the ability to effectively have kind of contracts where you say “I am designing it to have these properties,” and you can mathematically prove that it has those properties.

There’s a thing called formal verification. And you don’t have to do true formal verification, which is really hard, and it would’ve been basically impossible to do this with humans. Or incredibly expensive. But with LLMs, you can. And so I think we’re just gonna have to basically completely rewrite stuff. And that is actually going to be cheaper with AI than it’s going to be to do 1,000 bugs every six months. We should just redo these things.

I only tangentially understand this, but it seems reasonable enough. And, Stamos claims, not as hard as I would have assumed:

[It would take] less time than you might think. I think that’s actually one of the things that’s changed with AI. So I work at this company called Cognition now, and we have a product called Devin. And we work with companies, and we have these examples; like, we worked with Mercedes-Benz, and we rewrote one of these apps of theirs that would’ve taken months and months for humans to do. And we did it in like eight days. So I think actually this is one of those beliefs that software engineers have—that it’s impossible to do this. And it’s actually quite plausible.

[…]

We can’t just wait for these bad things to happen. We have to intentionally re-architect things. We have to intentionally rewrite things. We have to intentionally change how we do cybersecurity. We have to intentionally change how we build the networks. We have to intentionally change how we build security teams.

Right now, we’ve been very reactive. We still do patching like we did five years ago. Most security teams are still built like they were built five years ago. Like: The jobs are the same, the defensive structures are the same, how we do incident response is the same. And I think that’s a problem. And when I say “shorten the Dark Age,” what I mean is, we’ve kind of gotta actually utilize AI to proactively—we’ve gotta to make this better. Otherwise, we’re just going to try to patch-patch-patch our way through it. And that’s not gonna work.

I’ve seen others make similar arguments: While AI has made our systems much more vulnerable (or, rather, sped up the process of exploiting vulnerabilities that exist), it has also given us the ability to fix broken code and automatically patch software that otherwise would never have been updated.

More that I only partially understand:

Stamos: just think it’s total malpractice to write anything in C and C++. Any company that is shipping code that is written in C++ in 2027 is, from my perspective—that is just completely inappropriate.

Warzel: And for the people listening who aren’t as familiar, the reason for that is just ’cause it’s an old, outdated language. And you just don’t wanna have your systems be running off that. It’s easier to exploit all that, right?

Stamos: Right. Because the language C++—C and C++ are languages from the 1980s. The ’70s actually, and 1980s. And in fact, in the original book for the C programming language—which I was taught at Berkeley out of this book, in the original printing—there was a security flaw in the book that was written by the original authors of the language, right? Kind of famously. You can make mistakes, because these languages are what’s called low level. And you have to intentionally decide how you talk to the processor, and how you handle memory.

And so a lot of the kind of fundamental flaws that we see that get exploited these days is about deciding how you manipulate memory, the memory of the computer. You say, “I want to allocate memory. I wanna deallocate memory.” And the bugs that we see, like the PHP bug, these are memory-allocation errors.

In modern languages, these things are handled for you automatically. And in really modern languages, like Rust, you have the ability to say not just it handles the memory for you, but you can effectively say to the compiler—the software that takes what you say and then turns it into the language the computer actually executes. You can say, “This is what I intend. This is what I want to happen.” And so there’s double-checks, triple-checks to make sure bad things don’t happen.

Now, that would’ve been totally improbable in the 1980s, ’cause computers weren’t fast enough. It would’ve made the computers way too slow. But computers are incredibly fast now, and so these languages are much slower. But who cares? Because computers are spectacularly fast. We have way, way more speed, and so we sacrifice a little bit of speed for a lot more safety.

There’s quite a bit more to the interview, but it’s more in the weeds.

While I’m optimistic that we have the technological capability to make our digital infrastructure less vulnerable to bad actors, I’m skeptical that we’ll do so quickly and aggressively. It’s a huge coordination problem and we’re a deeply divided society, making it unlikely government will drive a solution.