The Amended Linus's Law

Marcus Hutchins posted something on LinkedIn back in May that's been rattling around in my head ever since, partly because I agree with him, and partly because I've been making the same argument for twelve years: on stage, in print, and in conversations with anyone who'd sit still long enough.

Marcus's observation, paraphrased: LLMs have put the "many eyes make all bugs shallow" myth to bed once and for all. If open source software really were more secure because anyone can audit the code, then a bunch of bots wouldn't currently be finding the easiest zero-days ever written in basically every codebase. The implication being that we've all been telling ourselves a comforting story about transparency that the evidence has now stopped supporting.

He's right. He's also, I'd argue, half-right, which is the most useful kind of right because it makes the other half visible.

Linus's Law isn't wrong. It's incomplete. The missing variable is incentive.

Twelve years ago I stood on a stage at SOURCE Boston and gave a talk called 5,500 Hackers + Your Code. I was twenty-something months into Bugcrowd, the wife and kids had been freshly relocated to San Francisco, and most of the conversations I was having with people about bug bounties still started with explaining what one was. Somewhere in the middle of that talk I borrowed a framing I'd first heard from another speaker (and credited from the stage, though the YouTube auto-captions have since helpfully mangled the attribution into nonsense) and called it the amended Linus's law:

With many eyes and the right incentive, all bugs are shallow. The key ingredient is what you're incentivizing. You need to connect the right incentive to the right outcome.

The whole talk, if you want to watch a slightly younger and considerably less grey version of me work through the argument in real time, is here:

That's the whole post in one quote, really. Everything else is just showing the work.

Stability bugs got found. Security bugs didn't.

Here's why open source software, broadly speaking, tends to be resilient and feature-rich while simultaneously being a target-rich environment for security researchers, and why those two things don't actually contradict each other once you look at the incentives.

Open source projects accumulate eyeballs from people who have a direct, downstream interest in the thing working. They're shipping commercial products on top of it. They're running it in production. They're the maintainer's friends. The bug they're hunting is the bug that breaks their build, crashes their pipeline, regresses a feature their customer depends on. That's a stability bug, or a missing-feature bug, and the incentive structure to find and fix it is extraordinarily well-aligned. Many eyes, right incentive, shallow bug. The system works exactly the way Linus described.

Security bugs are a different animal. The incentive to find them has historically been split across three parties whose interests don't compose: the maintainer (who'd rather not know, often), the downstream consumer (who assumes someone else is looking), and the security researcher (who's looking either as a hobby, for resume credit, or in some cases because the underground market has bid up the price of an exploit far above what the defensive economy offers). For most of open source's history, the cost of finding a security bug in code you didn't write was very high (you had to read it, model it, and prove the bug) and the upside was diffuse and fragmented. So the bugs sat there. For years. Heartbleed sat in OpenSSL for two years before anyone noticed, and Shellshock sat in Bash for roughly twenty-five. Both in code with arguably more eyes on it than any other open source project on the planet.

I said it that way on stage in 2014: the people looking at OpenSSL were perfectly capable of finding those issues. They just didn't have the right incentive to hunt the security flaw all the way down and deal with it. Stability won the budget; security got the leftovers.

That asymmetry, many eyes for stability and way fewer (with fragmented incentives) for security, is the thing that's been quietly load-bearing under everything we've called "open source security" for the last twenty years. It worked, sort of, mostly because the cost of discovery was high enough to limit the offensive side too.

The floor just fell out

What changed isn't the law. What changed is the cost of discovery.

The thing every defender has built their mental model on is that finding an exploitable bug in someone else's codebase requires a skilled human to spend skilled-human time on it. That's the part that's collapsing in real time. The bots Marcus is pointing at aren't smarter than the humans were. They're cheaper and more patient. You can now point an LLM at a codebase, give it a half-decent prompt, and have it surface plausible vulnerability candidates faster than you can triage them. Many of those candidates are noise. Plenty of them aren't. And the cost of the bot trying is approximately zero.

That changes the equation in two directions at once.

On the defensive side, it means the old "we'd notice eventually" assumption is dying. The window between a vulnerability existing and someone noticing it is compressing toward something close to instant, but only if you've actually wired up someone to be looking. If you haven't, you're now competing with everyone who has, on infrastructure where the bot doesn't get bored. This is why Marcus's suggestion in his post is the right one: someone should plot a graph of AI-discovered bugs in a codebase against bug-bounty and internal-security spend. I'd bet a steak dinner the correlation is exactly what you'd expect, and it's not subtle.

On the offensive side (and this is the part that's keeping me up) the same cost-of-discovery floor just fell out for the people whose incentive is, and always has been, positive feedback. To a defender, a bug is a thing to be closed. To an attacker, a bug is merely an undocumented access feature. They get paid when they find one and they get paid more when they keep it alive. They have a quantifiable, market-validated, positive-feedback incentive structure, and they're partying their faces off right now. This is only going to ramp once AI-assisted library patches with long supply-chain implementation tails start to land in the wild, because patches don't reach production at the same speed everywhere: they reach attackers first and laggards last.

What is a bug actually worth

I've been prattling on about this question, what is a bug actually worth, since Heartbleed and Shellshock, because it's the only question that produces durable answers about how to allocate defender attention. The answer is not "what does the maintainer's altruism budget cover." The answer is "what is the difference between the upside to someone finding it and fixing it, and the upside to someone finding it and weaponizing it." For most of the last two decades that gap was wide, and we got away with under-investing in the defensive side of the trade because the offensive side was also expensive.

That gap is closing. It's closing fast. And it's not closing because eyeballs got smarter. It's closing because incentives got teeth on both sides.

Marcus is right that the old story doesn't hold. The amended version, many eyes and the right incentive, is the one that does, and it's the one the next twenty years of defender economics needs to be built on. Pay people to look. Pay them well. Make the defensive incentive at least within shouting distance of the offensive one. Otherwise the bots will keep finding the bugs first, and they won't be working for your side.

Linus had the right idea. He just didn't finish the sentence.