Open source's superior security is a matter of eyeballs: Be kind to the brains behind them The speedrun is one of the internet's genuinely new artforms. At its best, it's akin to a virtuoso piano recital. Less emotional depth, more adrenalin. Watching an expert fly through a game creates an endorphin rush without the expense or time of doing it for yourself. twitchpokemon Hell is other people ... Thousands play …
Hell yeah! Let's switch to closed source software where more far more egregious issues are the norm because over there, unlike FOSS, doing it on the cheap *is* an actual business goal.
Remind me again, what's the current situation with closed-source SharePoint? Oh, right, if it's connected to the Internet it's compromised, and patching it won't fix it. What's the situation with closed-source Asus router firmware? Oh, right, if it's connected to the Internet it's compromised, and they won't even pretend to have the desire to patch it.
Yeah, I see. Closed source is such a better model. Clearly.
In reality that isn't the actual problem. It's so, so easy to believe that your troupe is the 'winner' in any game but the OP's post is proof that FOSS isn't doing what it says it is - inherently giving greater security.
If you're closed source it takes money to seek out bugs, money that is often not given as it is easier to turn your shoulder in the belief that everything is fine. The counter-incentive is the damage to both reputation *and* the bottom line when you lose market confidence or get sued for incursions (see: Delta v Crowdstrike, QSnatch, etc) so security, whist reluctant, often gets done. Just...late.
If you're open source it takes intellectual interest and manpower to seek out bugs in other people's codebase, brainpower that is often not given as it is easier to turn your shoulder because you have your own projects demanding your limited time, as well as believing that either the work is being done by someone else or unnecessary as the original coder "Is as skilled as me". So security is done on a willing-to-tackle, instead of a requirement, basis, rather than as quickly as necessary on the constantly-changing code base. So security often gets done, just...late.
So don't go trumpeting the logical fallacy that FOSS is, inherently, "Better", because it is "community based!". The FOSS ecosystem is inherently labor-limited: there are only so many coders of the necessary skill level multiplied by only so many coders willing or able to take up the workload. This creates security issues for FOSS code as large as those for closed-source code, no matter how much hype and self-aggrandization FOSS wishes to apply to itself.
A Sudo bug, just found last month, has been present for 12 years in the code...yet no one found it earlier. A breakdown of the history of discovered Linux vulnerabilities
https://sternumiot.com/iot-blog/top-linux-security-vulnerabilities-and-how-to-prevent-them/
isn't exactly promising, if we consider the "Many eyes on the code!" belief that has infiltrated FOSS for decades.
----------------------------------
The OP's point-of-fact stands: if FOSS were as good as the promise, HeartBleed, Sudo and Log4j, amongst others, shouldn't have been present without discovery for the many years they existed.
So stop the hype and understand that vigilance, in both closed-source and FOSS code, is absolutely required and a fundamental key part of the complex security web.
Remember, that if people with ill intent did find it, they wouldn't have told you. So you cannot prove whether or not anyone with ill intent knew of the vulnerability and they may have. What we know so far is that, as far as we know, no one has publicly indicated that this vulnerability was responsible for unauthorized access to their systems, but because people didn't know it existed, that wouldn't be easy to know either.
If OpenSSL's maintainers were smart, they'd have it so you can only review the source code after signing an NDA. I'm sure none of those fiascos would've occurred if they were allowed to sweep their quick-and-dirty decisions under the rug.
An unrelated excerpt from https://sappeur.di-fg.de/License.txt:
4.) Commercial users of the Sappeur Compiler need a written license per developer using the compiler. Cost of license per user is 300 Euro per developer-user.
4.2) Commercial users acquire the right to use all minor versions of a major version. The commercial license is tied to a major version. Use of a different major version requires an additional license.
5.) The source code of the Sappeur compiler might be made available on special request, based on a written non-disclosure contract.
9.) All users of the Sappeur compiler will accept the possibility of defects in the compiler source code and associated source code. Users will not demand any compensation from Dipl. Ing.(BA) Frank Gerlach for the effects of software defects.
11.) In order to protect Intellectual Property, the Sappeur compiler includes License Protection Technology(LPT). LPT needs to contact the web server http://gauss.ddnss.de for license checking. No source code is transmitted during this process.
We are frequently having to respond to customers of our (closed source) Java software that they have "found some issues" - what they mean is an automated tool has scanned the Jar and identified that we use SHA-1 or haven't disabled external entity resolution in the SAX parser.
What those tools don't spot is that we know about these issues and we're doing thiings securely. But I still have to send multiple emails back and forth explaining why this tool is not quite as insightful as the vendor claimed it was. Some clients take a bit of persuading.
Static code analysis has its uses, I just wish it framed its results as "you might want to look at this area of the code" not "OMG huge security fail".
A couple of years ago, my company was negotiating a round of funding. I found out when I got invited into a meeting with my CTO (boss) & COO at 4:45. The VCs were attempting due diligence, and had some fool with a scan tool go over our source. It flagged 15 critical issues and 50 high. The first one had to due with a java vuln. There was no java in our code. (My boss identified that & one other as bogus). It took me almost three hours to sort through the 13 remaining critical findings. (None of the 50 were real either, although I did have to pass a bit more than a handful to our lead dev to get confirmation).
So, no, I'm not going to get overly excited by static analysis tools.
It's not different than earing bead bought by your trusted baker, or eating bread found on the street.
Something that comes from a reputable supplier could be bad too, but you know there are some checks in place, and they will got out of business otherwise. Code found on the street, or the internet, of course has no such controls.
And while a relatively few skilled people can do the checks on their own, many others can't. And there's too much code, and generative AI will make it worse.
IMO, the reason FOSS was good at code quality and to a lesser extant security was that code was being ported to a variety of Unices running on different processors. This porting effort revealed a lot of bugs that would have taken longer to find had project only having one target.
Well unfortunately these days there is very little porting. Open source software is developed for Linux. Maybe it gets ported to macOS, but x64 and AArch64 are both little endian 64 bit architectures there is much less difference between them than in the days when there were 32 and 64 bits and little and big endian co-existing and being ported to.
Even the differences between Linux and macOS are a lot smaller (for user level CLI code at least) than the differences between Solaris, HP-UX and AIX were in the 90s when workstations ruled.
So porting is much easier - a lot of the time you just need to try to run 'make' a couple times and fix errors, with the first to include few header files, then maybe again to add an extra -l library or something. If you have to actually change the source code the changes are usually pretty minimal. So you see little or no source code so the chances that your porting effort uncovers an actual bug are pretty tiny compared to the 90s.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2026
