It's not even close! It's nearly two orders of magnitude higher for Linux.
This isn't anecdotal or “vague opinion” CVEs are facts.
You can ask the follow-up question: Why is that?
And there are many reasons.
It could just be that Linux having more users/eyes means more bugs are surfaced ...
But you need to dig deeper to understand why OpenBSD is so much more secure,
the core team of OpenBSD proactively reviews the security of other OSes and when they learn something, they rapidly implement the feature/fix in OpenBSD.
Again, read: https://en.wikipedia.org/wiki/OpenBSD_security_features
Many of the proactive security features OpenBSD has are not implemented by other OSes. And in the case of kernel-level Crypto, they won't ever be because US export restrictions.
> And there are many reasons. It could just be that Linux having more users/eyes means more bugs are surfaced
You really brushed that one off, uh? The ratio of linux devices to openbsd is quite literally a million to one. The ratio of tech companies invested in linux to companies invested in openbsd is roughly 50,000 to 1. The ratio of professional security researchers paid to find flaws in Linux vs OpenBSD is harder to quantify at the moment, but I think we can guess a trend here.
I can agree to a degree that OpenBSD takes security more seriously, and they have made very interesting design decisions to enforce their security model. But I entirely disagree that the number of "CVEs are facts" to back your opinion that it is superior.
> This isn't anecdotal or “vague opinion” CVEs are facts
No they aren't, they're data. Your source shows the amount of Linux CVEs in 2024 are an order of magnitude higher than the amount of Linux CVEs in 2023. Does that mean Linux became way more insecure in 2024? You imply it does, but that's obviously not true. What happened is that Linux changed how they report CVEs [0].
Just like your source doesn't say anything useful about the difference in CVEs in Linux, it doesn't say anything about the difference in CVEs between Linux and OpenBSD.
This announcement thread really isn’t the place to discuss or debate the data.
The OP stated they couldn’t find any data to compare the relative security of Linux vs. OpenBSD.
CVEs are independently, objectively verifiable and provable data. This is the dictionary definition of a verified “fact”. It’s not anyone’s opinion.
You don’t have to like it or me.
Going by CVEs, Haiku is more secure than OpenBSD. Linux has had strong kernel-level crypto enabled by default on major distributions for years, see AF_ALG or LUKS.
On the wiki page you provided, the only thing that really stands out at the kernel level is KARL, which has a dubious utility: https://isopenbsdsecu.re/mitigations/karl/ It is not even up to date: strlcpy(3) and strlcat(3) were implemented in glibc 3 years ago.
> I would be in favour to say that out of the box OpenBSD is more secure than Linux.
Also important to remember that diversity builds strength. Just as in biology, if all organisms are the same, they all succumb to the same virus.
I have a multi-layered firewall approach where some are Linux, some are OpenBSD, some are commercial. They'll all have bugs, but unlikely they all have the same bug.
You are correct; OpenBSD is secure by default. And it's not subjective at all.
The homepage of https://www.openbsd.org proudly states "Only two remote holes in the default install, in a heck of a long time!" if they didn't have the evidence to support the statement, the internet would have forced them to remove it by now. ;-)
Remote (exploitable) holes are the ones we all care about.
The key (and not saying it's bad, mind you) is that the default install has very few services installed, let alone running or open.
So even if Debian and OpenBSD ship the exact same web server, but Debian has it defaulted installed and on, but OpenBSD does not, then a remote exploit won't count against OpenBSD.
All OpenBSD services, including HTTP (httpd), SMTP (smtpd), and DNS (nsd, unbound, unwind), use privilege separation and sandbox themselves with pledge and either unveil or chroot. There's no extra configuration. And the developers dog-food these services; it's why they're in the base system.
How many Linux services use seccomp? Or chroot, mount namespaces, or landlock? If they do at all, it's usually imposed externally by systemd or docker, in which case they usually run with overly broad permissions because there's no integration with the specific application code, thus the AF_ALG exploits in containers. On OpenBSD services continue to narrow their privileges after starting up so by the time an external request is serviced they have only minimal access to syscalls and the filesystem, often only read/write/send/recv syscalls, and if open is allowed only the specific files and directories needed to service requests. Typically even the network-facing daemon accepting TLS connections doesn't have access to the private key--you simply can't do that by running a vanilla service application in docker.
Does OpenBSD have bugs? Of course. The question is, which environment has more trustworthy backstops? The Linux kernel provides all the facilities, but they're not used effectively, for many reasons.
Isn't that a good thing for certain use cases ? If you are building an appliance type thing (say a storage or networking device) then you would want something minimalist you can add only the necessary services on. And arent those the types of devices the BSD (in general) are used for ?
Less attack surface always equals less potential for bugs/flaws/exploits regardless of how good red teaming tools and workflows get.
Now obviously for other use cases Linux could be a much better option.
There was a time when Linux distributions shipped lots of things on by default; OpenBSD bucked the trend and did not. This is less of an issue nowadays.
> This was the most critical vulnerability we discovered in OpenBSD with Mythos Preview after a thousand runs through our scaffold. Across a thousand runs through our scaffold, the total cost was under $20,000 and found several dozen more findings.
I'm saying you don't even need Mythos to find bugs in OpenBSD. GPT 5.5 is SO much better than humans at finding these things.
The fact that we don't even need Mythos, or $20k (I just pay $24/month and this was one of my MANY uses), to find bugs in OpenBSD shatters the dream that there exists any human who can write C properly with enough expertise, dedication, and time.
As I mentioned in the post, I only did a brief exploration of OpenBSD in order to cheer myself up. I took some findings, confirmed them being true bugs, and ended there.
As I said in the out of bounds null termination write patch, I don't believe it's exploitable. I would have gotten a CVE, website, and logo then (kidding!). But it was UB. And one-byte overflows have in the past been exploitable by better sploit authors than me.
In any case, I reported that since I felt it was clear that OpenBSD folks would obviously care about it, exploitable or not.
Confirming these findings take time, even though I found GPT to almost always be correct. I will NOT report upstream until I understand the bug. I ain't no slop reporter. As I said in the post OpenBSD (and all other code bases) need a larger effort. The Mythos/Glasswing effort focusing on actually exploitable ones may be a good method for getting them fixed, without overwhelming projects with patches, even when the patches are correct.
I did confirm at least one more UB, and did consider whether to report that OpenBSD `find` reads `status` via `WIFEXITED(status)` without checking `waitpid()` for errors. This is UB since `status` is uninitialized.
(https://github.com/openbsd/src/blob/ae684bfaed6cae797cd90e27...)
The reason is my previous experience with OpenBSD where the reply may be "<some standard> is wrong in this regard", and because they control their whole system, they don't care. E.g. in this case they may go "we build with GCC x.y.z exactly, and we know what actually happens in this controlled domain". This may be a bit unfair to them, but not by much.
GPT also flagged the extremely surprising behavior of running `cat -n file1 file2` if file1 doesn't end with a newline. And that `find /etc/passwd -execdir[…]` doesn't run the command. But maybe that's how they want it? I don't want to go through the whole thing for them to go "yeah we won't do that" again. So I think this project is for them. GPT is as available to them as it is to me.
Tangent: in running GPT against `cat` I learned that not only is `cat -n` not standardized, but it also behaves COMPLETELY differently than on Linux, if you provide more than one file.
It's not meaningfully more secure than e.g. Debian.
Their claim to fame ("only two remote holes in the default install in X number of years") is definitionally only valid for the default install in its default configuration which means: no httpd, no smtpd, no unbound, etc. etc. etc.
The default install isn't very useful, because it doesn't do a lot, and so "only two remote holes" or whatever isn't really saying much.
Linux has more CVEs because it's orders of magnitude more popular. OpenBSD has appalling performance, and more or less nobody uses it, so there just isn't a large focus on auditing and fixing it.
It's a great research project, but I would not run it on my personal devices. Not because it's "insecure" but because the putative security benefits do not merit the shockingly poor performance.
> The default install isn't very useful, because it doesn't do a lot, and so "only two remote holes" or whatever isn't really saying much.
Thats not really true. Comes with spamd, pf, httpd, OpenSMTPD and others. Its actually one of the open source unix-like systems that packs more functionality out of the box.
Great firewall and VPN server. You can setup wireguard with just ifconfig.
I get your point, but GP is right: You said "Default install", not enabled by default.
The default install is actually very useful, and includes a lot, like parent said. Having run OpenBSD in the past, I found the their versions of things were often superior, at least for small setups (and some of them for large installs as well.. probably : )
I use it on my ~10 year old desktop as my everyday OS. Performance may be measurably worse on benchmarks, but I never notice it doing regular stuff as a user. It's fine.
Easy to install and upgrade, sane defaults, good documentation, lack of waffleburgers of complexity, so I'm not sure why anyone wouldn't run OpenBSD in the first place. Granted I put Windows in the unusable bin and it's been there for decades now and sounds like it is getting worse, what passes for Mac OS X these days is not so good given that you have to disable some security thing to properly kill the annoying and disruptive notification system, among other annoyances still being fueded with, and I gave up on Linux after trying to support that waffleburger in production for a year or two.
With due mention to FreeBSD's jails, BSD's security image developed mostly from OpenBSD which is said to have gained its security focus due to NetBSD being so insecure that the NetBSD folks were able to hack into DeRaadt's forked OpenBSD.
Android's Bionic was based on or heavily influenced by OpenBSD's libc iirc, though.
No, not really. Linux has better options available and is significantly stronger when configured correctly. The OpenBSD approach ls largely based around eliminating bugs in the first place, but isn't as strong at limiting an attacker that successfully exploited a bug they missed or weren't responsible for.
These are the operative words. With OpenBSD, you get this out of the box and everything just works. With other operating systems, you have to do a lot of the legwork that's already been done for you with OpenBSD and make sure you didn't break things with your configuration.
These are words that when applied equally to Linux and OpenBSD, has Linux coming out ahead.
> With OpenBSD, you get this out of the box and everything just works.
With OpenBSD, out of the box you get a blank slate that really can't do anything, that you have to configure to do what you want, and currently can't be configured to be as secure as linux can be.
Sorry but that's simply not true. There are various cases where vulnerabilities didn't affect OpenBSD due to defense in-depth in OpenBSD.
OpenBSD has a pretty long history of eg. limiting attacks through compile time mitigations while making them more usable for every day use compared to specialized "high security" Linux distributions. This can also be seen in patches of third party software (in the ports (packages) system) that often have patches so the code can live with these limitations.
One example of such a mitigation is W^X. Implemented in OpenBSD in 2003, copied later by Windows, Linux and the other BSDs (incl. macOS).
More recently of course pledge and unveil were also added.
Also in 2003 OpenBSD was also the first mainstream (no research or test OS) that implemented strong ASLR that in 2005 was supported in Linux through third party patch sets.
It really is true. OpenBSD focuses on auditing. In many cases they were not affected because of mitigations, but because they were just using a different stack. OpenBSD wasn't affected by regreSSHion for example, for basically the same reason Alpine wasn't.
OpenBSD didn't invent the concept behind W^X, and if you want to talk of 'copying', which I think is kind of silly personally, then PAX was first.
I'm familiar with the list of OpenBSD innovations, and in turn I would point you to https://https://isopenbsdsecu.re/ for a breakdown of their claims and marketing.
To this date OpenBSD doesn't have anything as simple as a proper ACL, let alone any type of MAC. They claim such systems are too complex, which is of course nonsense.
It's like I said - they focus a lot on preventing an attacker gaining access, but have little available to constrain attackers who DO get access.
> there are numerous other things that are done for mitigation outside of this.
Sure, and I think they are mostly great, main problem being they just don't go far enough. Where's the namespace level isolation, ACL or MAC support? Is there a way to give a user append only ability for one file, while having write but not delete access to another, and delete to yet another? What's the maximum extent to which OpenBSD could have limited an attacker, had they been vulnerable to regreSSHion?
Compare the number of CVE vulnerability trends over time between Linux: https://www.cvedetails.com/vendor/33 and OpenBSD: https://www.cvedetails.com/vendor/97
It's not even close! It's nearly two orders of magnitude higher for Linux. This isn't anecdotal or “vague opinion” CVEs are facts.
You can ask the follow-up question: Why is that?
And there are many reasons. It could just be that Linux having more users/eyes means more bugs are surfaced ... But you need to dig deeper to understand why OpenBSD is so much more secure, the core team of OpenBSD proactively reviews the security of other OSes and when they learn something, they rapidly implement the feature/fix in OpenBSD.
Again, read: https://en.wikipedia.org/wiki/OpenBSD_security_features Many of the proactive security features OpenBSD has are not implemented by other OSes. And in the case of kernel-level Crypto, they won't ever be because US export restrictions.