There is another take on "heavily audited". Many OSs and eg. browsers have the issue that there are huge amounts of pretty complex codes. OpenBSD is extremely inviting and among actual general purpose operating systems used on a daily basis in production one of the projects that sees a quite big amount of reads because of the relative simplicity and (intentionally) low amount of code.

Really, try making sense of pretty much anything in the Linux kernel compared to the OpenBSD kernel or any of the bigger browsers. Like fully grasping it. There is worlds in between.

This has secondary effects of people actually looking at code that is not their area of expertise and developers also working outside their subsystems.

Meanwhile in eg Linux you have huge swaths of code that essentially only some guy in some company somewhere has somewhat of a grasp of. And that's where Linux constantly sees its vulnerabilities, while OpenBSD actively removes such things, eg they removed Bluetooth support back in 2014. This leads to a situation where people actually are able to dig into things. They also have a huge amount of guardrails turned on and I know people that compile their code on OpenBSD despite not targeting the OS at all because of those guardrails uncovering issues.

Think about any bigger software company. There is a huge chance you basically have no idea how the stuff outside your team works maybe not even all of your team.

These kind of are the attack vectors we see in Open Source all the time (and actually closed source software too). It's not the stuff that everyone uses and wants to understand deeply in browsers that cause exploits. It's that one tiny thing that is part of the standard or somehow support was added, but despite nobody using it it's still there, either because well.. it's a standard or because nobody bothered to remove it.

OpenBSD even decided to break some standards for security reasons, but that's another topic.

What I wanna say with that is: I can think of a lot of projects that have more devs and more people looking at parts of it, but these projects tend to be quickly changing huge codebases, where no single person can have a good understanding of everything. This means that there is a good likelyhood that parts are not audited until some group or individual comes along and picks such a bit.

It's actually also what likely happened in this case, given it's 37 years old.

This isn't to defend OpenBSD, but to point out that X amount of people doesn't mean much without taking the size of the audit into consideration. I would think that big projects is something where LLMs really shine, but I also think that reducing attack surface by reducing code and complexity might be the biggest defense and as far as I have seen OpenBSD does a great job there and should be considered something that others can learn from.

And it's not just these kinds of software. It's not even just software per se. It's also infrastructure, where complexity usually means increased attack surface. And just to be clear: One always adds complexity, but it should be the minimal amount to fulfill the goal and not more and try to not add side goals you don't actually care about and want to maintain.

Especially with LLMs it's so incredibly easy to add complexity only for tomorrow's LLM (or human) to find huge amounts of bugs.

Big Fish: Exploiting a 37-Year-Old Kernel Bug in OpenBSD