Remember Linus's Law? While it was never really true, there are now A LOT of people looking for vulnerabilities with LLMs, and they're finding vulnerabilities EVERYWHERE

While Linus's Law was clearly nonsense, this is creating an increase in vulnerabilities the world is completely unprepared to deal with

What happens if we have a million CVEs every year?

https://opensourcesecurity.io/2026/04-linus-law-vulns/

@joshbressers https://blog.liw.fi/posts/2022/04/07/linus-law/

@liw hi5!

@joshbressers maybe.... fix them slowly, and write new code more slowly, carefully, and deliberately?

@hyc While I would love to see this, I suspect that ship sailed a long time ago

@joshbressers

A million CVEs is gonna look like rookie numbers in 3-5 years. The quantity of vulnerabilities will increase with the quantity of code and that's ballooning now.

Thing is, any pentester or appsec person could have told you this stuff is there and has been forever. It's occult knowledge basically; hidden because nobody's actually been looking.

The reckoning here isn't that this is creating some unbeatable tide of new problems, it's that for years people have refused to foundationally build in secure design and development practices in our education for any kind of programmer, developer, or architect. Pushing left is the only reliable way to turn this tap off - prevent the mistakes as or before they're made. Instead, the industry has collectively decided to build tap opening automation at grand scales.

"Oh no we've defended our appsec program" is basically where loads of companies are.

Look to climate change for how well we're goanna handle this.

#InfoSec #AppSec

@fennix Agreed!

It's going to be a very silly couple of years

@joshbressers I'm not so sure. Everyone jumping on the "AI is 100x more productive than human programmers" bandwagon is going to crash and burn. The survivors who learn the lesson will get back to code written thoughtfully.

@hyc @joshbressers the problems these AIs find now are the bugs we introduced back when we still wrote things slowly and what we thought was carefully...

If we fix them slowly now, we just get a backlog that grows.

@joshbressers What if most of them are bullshit?

https://www.flyingpenguin.com/the-boy-that-cried-mythos-verification-is-collapsing-trust-in-anthropic/

@haliphax While the hype around Mythos is overblown, this isn't about Mythos. Any LLM an find vulnerabilities because there are A LOT of vulnerabilities in everything

@joshbressers with that many cve's, no one is going to take them seriously. What's the point of fixing some, when thousands of new ones pop up each day...

@Strit That's one of the possible outcomes, yeah

@bagder @joshbressers Yeah, sometimes life just sucks. If you use AI to "fix" them quickly now, you just get a codebase that *nobody* can fix in the future.

There is no better alternative than fixing things slowly.

@hyc @joshbressers I didn't say nor imply you'd use AI to fix them, only that doing it slowly won't really work.

@bagder @joshbressers and yet it's the only thing that will work.

It means every affected project must impose a moratorium on new features and work exclusively on patching holes. That's the only way to keep the backlog from growing. And this has always been true, even before AI detection of vulns was a thing.

@hyc @joshbressers someone the other day mentioned his hobby project that they spend an hour or two per month on suddenly getting 30 security reports that month. That person didn't work on adding many features, he was just working on his little thing. Now they will have a backlog to fix bugs for a long time. Of course such an event will be problematic to many humans.

And then get 30 more ones the next month. And the next.

@bagder I dunno... if you're getting 30 unique bug reports every month on your toy project, maybe you need to take it offline and stop offering it for others to use. That's just really bad coding.

If you're getting 30 *duplicate* bug reports every month, I think you just start filtering them out...

@hyc with that logic, most of the software projects in the world should now be taken offline for a while

@bagder Yep.

It feels like M$ made the entire world desensitized to poor software quality. And the consequences are biting now.

@hyc We did not find these bugs before and now we do. That's not any single company's fault.

@joshbressers perhaps a silver lining is that GenAI can be decent for producing much of the vulnerability documentation, even if it's not so useful for writing the fixes.

@joshbressers Is there any estimate on what percentage of this potential new wave of vulnerabilities are tied to unchecked array bounds? Is this pending tsunami going to make more projects reconsider converting to a memory-safe language?

@scottmiller42 The bugs are all over the place. And I don't think this will change many minds about moving to memory safe languages

The people who like C like C because it's C :)

@joshbressers if what's happening to Firefox is any indication then they will run out of real, serious vulnerabilities rather quickly and these tools will start spitting out more and more false positives. It'll just be a bump in the road.

@joshbressers @haliphax that may be true, but what I'm winding up spending a ton of time on as a result isn't a pile of vulnerabilities, it's a ton of minor bugs that I need to document aren't vulnerabilities.

@joshbressers @scottmiller42 you make it sound like not being C is a problem with rust, but that's not it. One of the big problems is that it's the best C++ dialect, and we don't want C++.

@joshbressers nothing? We are still patching and were already easy to pop before. We may just lose the illusion of protection we used to have

@vathpela @haliphax

That's true. The volume of noise is without question a bigger problem

And even if it's not "just a bug" a lot of the vulnerabilities are going to be technically correct, where they don't really matter, but the reporter will demand a CVE

@vathpela @joshbressers FWIW, I deliberately avoided using the R word to avoid language debates.

I'm just going to say when the entire world is on fire and all the buildings are on fire, and you (Josh) say we don't have enough firefighters, and the ones we have are resigning in exhaustion... maybe we stop making the buildings out of oily rags and paraffin-soaked paper?

@vathpela @joshbressers In the spirit of trying to be constructive, I have looked at Rust a bit, and as someone who has coded professionally in both C and C++, I can see a bit of why people might not like it.

If someone can memory safety to C in a way that otherwise is extremely minimal in how the new code looks, great. I'm not an expert in developing programming languages, but I can see how that might be challenging given a few C things like the language is not type strict.

@scottmiller42 @joshbressers yeah; there are a couple of experiments in doing it out there (Cyclone, for example) and they're not great. I do think there's an un-explored way to do much of what's needed with parse tree analysis and annotation formats like annobin, but AFAIK nobody is actually working on anything like that (and I certainly don't have the time.)

@scottmiller42 @joshbressers No matter what there would definitely be a lot of "you just have to fix old code to not do X", and a fair amount of "you need to make this function behave in a more legible way because the scanner just isn't that good (yet?)".

@gregkh @joshbressers @vathpela @haliphax
Auto-assign a CVE to every PR. It saves a lot of time later. 💁🏻‍♂️

@icing @gregkh @joshbressers @haliphax Just one?

@icing @gregkh @joshbressers @vathpela @haliphax we just need to define that the commit id is the cve identifier