28 Years Later: Some Things Changed. The Important Stuff Didn't.

In May of 1998, I sat at a witness table in a Senate hearing room with six other members of L0pht Heavy Industries and told a room full of United States senators that the internet, the one they were increasingly betting the future of the country on, was fundamentally broken. We said we could take it down in thirty minutes. We meant it. The senators nodded gravely, thanked us for our time, and largely went back to doing what they were doing before.

Twenty-eight years is a long time to watch an industry grow up. I've had a front-row seat – sometimes an uncomfortable one – in the middle of the action for most of it. The security industry went from a loose collection of curious people breaking things in basements and run down warehouses to a global enterprise worth hundreds of billions of dollars. We now have certifications, conferences, compliance frameworks, threat intelligence platforms, zero-trust architectures, and enough acronyms to choke a data center. And yet the fundamental conversation hasn't changed as much as it should have.

Give Credit Where It's Due

Let me tell you what actually changed first.

Awareness is genuinely different. In 1998, explaining to a senator what a vulnerability was required starting from scratch. Today, CEOs know what ransomware is because their company got hit by it, or their friend’s company did. Board-level security conversations happen now in ways they simply didn't two decades ago. That's real progress, even if it was purchased at the cost of a lot of painful incidents. The security community spent years screaming into a void, and eventually the void started listening, mostly because it started hurting.

Better Tools, Bigger Community

The tooling has also improved dramatically. The ability to identify, triage, and respond to threats at scale would have seemed like science fiction to the version of me sitting in that hearing room. Automation, detection engineering, modern SIEM and EDR capabilities, these are genuinely better than what we had back then, if we had them at all. The defenders have real weapons now, not just duct tape and stubbornness.

And the talent pool. The community has grown in ways that still impress me. There are brilliant people working this problem from angles we weren't even considering in the late nineties. That matters.

Here's Where I Get Difficult

Now here's where I'm going to be the grumpy old man shaking his fist at the sky who just won't let it go, we are still losing the upstream battle.

The fundamental problem we identified in 1998 wasn't just that the internet had vulnerabilities; it was that we built critical systems on a foundation that was never designed to be secure, and we were iterating on that insecurity faster than we were addressing it. Ship it, patch it, breach it, apologize for it. Rinse and repeat. We called that out explicitly. We said the architecture of trust underlying the internet was broken, and that patching individual flaws wasn't going to fix it.

That cycle is still running. We've just industrialized it.

It Was Always the Code

Here's the thing that still keeps me up at night: the vulnerability usually isn't in the perimeter, it isn't in the network, and it increasingly isn't even in the configuration. It's in the code. It was always in the code. A SQL injection from 1998 and a SQL injection from 2024 are the same mistake made by a different developer who didn't have the right context at the right time. We've built extraordinarily sophisticated systems for detecting when attackers exploit the code we wrote badly. And we've invested comparatively little in not writing bad code in the first place.

The security industry has historically been more comfortable selling locks than teaching people to build better doors. That's partly economics: breach response is urgent in a way that prevention never feels until it's too late. Partly it's a culture problem. Security teams and development teams spent a long time talking past each other, operating in separate worlds with separate incentives. The security person finds a vulnerability six months after the code shipped. The developer has moved on to three other new features. The fix is painful, the blame is diffuse, and nobody really learns anything.

And Then There's AI

And then there's AI, which manages to be both the most promising development I've seen in years and a potential accelerant for the exact problem I just described. Let me explain what I mean. AI-assisted code generation is real and it works, and developers are using it whether security teams are ready or not. That means we are producing code faster than at any point in the history of software. More code, more surface area, more potential for the same classes of mistakes we've been cataloging since the nineties, just at a scale that makes the old patch cycle look quaint.

At the same time, the application of LLMs to static analysis is genuinely interesting. The gap between "this tool flagged a potential vulnerability" and "this tool explained why it matters, in context, in language a developer can act on" is closing in ways that could actually change behavior rather than just generate tickets nobody reads. AI integrated directly into the IDE, catching the problem at the moment of creation rather than in a scan report three weeks later, is the closest thing I've seen to addressing the cultural disconnect at the source. I'm not ready to call it solved. I've been in this industry too long to call anything solved. But for the first time in a while, the trajectory of the tooling feels like it might be aimed at the right target.

The Shift That’s Actually Happening

That's starting to change, and I'll be honest, it's one of the things that makes me less pessimistic than I probably sound. There's a growing recognition that security has to live where the code lives, that the developer writing the code is the first and most effective line of defense, not a liability to be managed after the fact. Catching a vulnerability in a pull request, before it ever ships, is categorically different from catching it in production. The economics are different. The blast radius is different. The learning opportunity is different.

The tools that make that possible, like static analysis that actually works at scale and security feedback that fits into a developer's existing workflow without requiring them to become a security expert, represent a more honest attack on the root cause than another layer of runtime detection. Not instead of detection. In addition to it. But the needle doesn't move until we get serious about the code.

Twenty-eight years ago, we were trying to get policymakers to understand that the problem was real and structural. That part worked, eventually, mostly. The next 28 years of work is getting the industry to internalize that the leverage point is upstream, that the most powerful thing we can do is make it harder to introduce the vulnerability than to introduce the feature. That means security and development working together as one function, not separately as two functions in tension. It means giving developers real tools with real context, not just a list of CVEs and a shrug.

The Work We Know How to Do Now

The senators back in '98 asked us what the solution was. We told them there wasn't a quick one. That was true then. It's still true now. But we know more about where the work actually needs to happen. That's not nothing. That's where I'd put the next 28 years.