There are always more left.

And memory safety doesn't prevent logic errors (or using 4 as a private key for that matter)

This said memory unsafe code just likely has more bugs because of all the footguns it has on top of all the other security work you need to do with it.

No, but type safety does. You can't forget to lock an object before using it when that lock is part of the type. Or pass a raw user controlled path to a function that expects a validated one. If you want to do it on purpose you need to write unsafe code that's clearly visible to anyone reviewing your patch.

[delayed]

[delayed]

Is anyone spending millions of dollars on checking OpenBSD?

But it also got its share of use-after-free and OOB access vulnerabilities this year: https://feedly.com/cve/vendors/openbsd

[delayed]

Yep, the reason why OpenBSD has had 5 times as many security vulnerability reports in 2026 than in 2025 has to do with the fact that OpenBSD is more secure and the reason is the code.

It was designed to have its vulnerabilities discovered in the year of agentic AI.

As an OpenBSD lover and frequent user I will tell you it does not support but a significant fraction of the hardware Linux does, and has many features that are reduced in functionality or just gone compared to Linux.

Is it bulletproof? Definitely! But you need the genius of Albert Einstein as well as the patience of Mother Theresa to actually use it in production.

For most server setups OpenBSD's hardware support is adequate, and this is especially true for VMs. It's laptops, peripherals, and bleeding edge, high-performance or specialized devices where driver support is a PITA. But that's not something I've encountered running my own private servers. It would be nice to have something like ZFS, but mostly that's a peace and convenience thing--would be nice to be able to stream backups somewhere rather than push around dumps and tarballs, though I have a script for that.

Can't have a bug in a feature you never implemented and can't have another arising from unexpected interaction of two features you didn't implement.

It's the one security practice that actuuuualy works

literally just got a syspatch email bruh

We finally got the sufficiently smart C programmers and you still think that humans are part of that group?

More than half of those lines are from drivers, drivers which wouldn't be relevant to a VM environment. Core kernel code for any particular architecture is less than 10 million, but some of that is filesystems or subsystems not in use or available to an unprivileged user on a typical server, so possibly maybe 5 million or less. And the article says they only targeted 2.8 million SLoC.

Because these are also some of the most meticulously polished and reviewed 40+ million lines of memory-unsafe code, with the critical paths and anything having to do with privilege escalation having been pulled apart over decades by independent and / or state actors, bots, fuzzers, etc.