It's not as heavily audited as you think. They have like a dozen active developers.

Heavily audited might be a stretch. Who did the audit and what knew to look for is key. I wonder if they are using agentic tools to help improve the frequency and quality of their audits. Volunteer time is precious and getting robots to help might be useful, but I can also see it taking more of that same volunteer time to get good results from the robots. Either way, its their project and and they'll do as they deem fit, which is totally fine.

Every blog post on this site is AI generated and covers bugs and exploits that were uncovered also by AI

So, sort of like fuzzing. There's a scary amount of exploitable stuff like this sitting in every BSD and Linux system out there, including every embedded system running old kernels in routers, cars, plcs, on and on

>in one of the most heavily audited codebases

The idea of "OpenBSD is super duper secure" is mostly a fiction. Their prime claim to fame, "only two remote holes in the default install in a squillion years", is pretty meaningless because the default install doesn't really do anything, so as soon as you install packages to make the system useful you're beyond their security claims.

Classified workstations in National Security contexts? They run Windows.

Red network routers? They're Cisco, Juniper, PAN, etc. It's all COTS stuff. OpenBSD is mostly a LARP.

Not that remarkable. Nobody in history has been able to write correct C code, and that includes OpenBSD developers.

I pointed an AI at the smallest two tools in OpenBSD I could think of, cat and find, and found multiple bugs. One of which was a buffer overflow (albeit unlikely to be exploitable). IIRC these bugs had existed since at least the NetBSD/OpenBSD split.

Everything in C is UB: https://news.ycombinator.com/item?id=48203698