1d ago

Why is open source software assumed to be secure?

I support free and open source software (FOSS) like VLC, Qbittorrent, Libre Office, Gimp...

But why do people say that it's as secure or more secure than closed source software? From what I understand, closed source software don't disclose their code.

If you want to see the source code of Photoshop, you actually need to work for Adobe. Otherwise, you need to be some kind of freaking retro-engineering expert.

But open source has their code available to the entire world on Github or Gitlab.

Isn't that actually also helping hackers?

43 comments

Otherwise, you need to be some kind of freaking retro-engineering expert.
Nah, often software is stupidly easy to breach. Often its an openly accessable database (like recently with the Tea app), or that you can pull other data from the webapp just by incrementing or decrementing the ID in your webrequest (that commonly happened with quite a number of digital contact tracing platforms used during Covid).
Very often the closed source just obscures the screaming security issues.
And yeah, there are not enough people to thorouhly audit all the open source code. But there are more people doing that, than you think. And another thing to mind is, that reporting a security problem with a software/service can get you in serious legal trouble depending on your jurisdicting - justified or not. Corporations won't hesitate to slap suit you out of existance, if they can hide the problems that way. With open source software you typically don't have any problems like this, since collaboration and transparency is more baked in into it.
Others have mentioned this, but to make sure all context is clear:
FOSS software is not inherently more secure.
New FOSS software is probably as secure as any closed source software, because it likely doesn't have many eyes on it and hasn't been audited.
Mature FOSS software will likely have more CVEs reported against it than a closed source alternative, because there are more eyes on it.
Because of bullet 3, mature FOSS software is typically more secure than closed source, as security holes are found and patched publicly.
This does not mean a particular closed source tool is insecure, it means the community can't prove it is secure.
I like proof, so I choose FOSS.
Most people agree, which is why most major server software is FOSS (or source available)
However that's also because of the permissive licensing.
It's not "assumed to be secure." The source code being publicly available means you (or anyone else) can audit that code for vulnerabilities. The publicly available issue tracking and change tracking means you can look through bug reports and see if anyone else has found vulnerabilities and you can, through the change history and the bug report history, see how the devs responded to issues in the past, how they fixed it, and whether or not they take security seriously.
Open source software is not assumed to be more secure, but it's security (or lack thereof) is much easier to verify, you don't have to take the word of the dev as to whether or not it is secure, and (especially for the more popular projects like the ones you listed) you have thousands of people with different backgrounds and varying specialties within programming, with no affiliation with and no reason to trust the project doing independent audits of the code.
Because "some nerd out there probably would have found any exploits for the X years its been released" is the general assumption about open source software.
The code being public helps with spotting issues or backdoors.
In practice, "security by obscurity" doesn't really work. The code's security should hinge on the quality of the code itself, not on the amount of people that know it.
- It also provides some assurance that the service/project/company is doing what they say they are, instead of "trust us".
  Meta has deployed code so criminal that everyone who knew about it should be serving hard jail time (if we didn't live in corporate dictatorships). If their code were public they couldn't pull shit like this anywhere near as easily.
- Yuup. “security by obscurity” relies on the attacker not understanding how software works. Problem is, hackers usually know how software works so that barrier is almost non existent.
- The code being public helps with spotting issues or backdoors.
  A recent example of this is to see the extent that the TALOS group had to do to reverse engineer Dell ControlVault impacting hundreds of models of Dell laptops. This blog post goes through all of the steps they had to take to reverse engineer things, and they note fortunately there was some Linux support with publicly available shared objects with debug symbols, that helped them reverse the ecosystem. Dell has all this source code, and could have identified these issues much more easily themselves, but didn't and shipped an insecure product leaving the customers vulnerable.
With open source code you get more eyes on it. Issues get fixed quicker.
With closed source, such as Photoshop, only Adobe can see the code. Maybe there are issues there that could be fixed. Most large companies have a financial interest in having "good enough" security.
One thing people tend to overlook is: Development costs money. Fixing bugs and exploits costs money.
In a closed source application none will see that your software is still working with arcane concepts that weren't even state-of-the-art when written 25 years ago. The bug that could easily be used as an exploit? Sure, the developer responsible for it did inform his manager around 50 times he needs time and someone from the database team to fix it. And got turned down 50 times as it costs time and "we have to keep deadlines! And none noticed this bug so far,so why should now notice now?"
- Lots of open source software uses arcane concepts because lots of it is old. See Xorg as a prime example. That was outdated 20 years ago already.
  Closes source software gets exploited and hacked all the time. They take security seriously as well.
  Look at OpenSSL and the heartbleed and similar high profile security failures for how even using high profile open source software is not automatically more secure.
  
  You didn't get my point: On Open Source people know. People know that Xorg is using arcane concepts and as a client you can pay someone to get through the code. Or a governmental institution can. (And yes, mine does with public reports)
  This is not the case with closed sources. You will only know when someone has exploited it. And while closed source applications like Windows,Office,etc. are having enough public weight that a lot of people with good intentions see them as a "challenge" and test for exploits. This is already not the case for smaller,but often critical applications. And no,most commercial closed source applications don't give a fuck about security - even in critical infrastructure. I worked as a PM for these applications in the past and my company now consults for critical infrastructure. The status of security in niche applications is abhorrent. The longest running major exploit I stumbled upon was 22 years old. And left around 65% of all water treatment plants of a smaller nation at risk. (It's fixed now. Not because they wanted to, but because someone forced them to)
One thing to keep in mind is that NO CODE is believed to be secure…regardless of open source or closed source. The difference is that a lot of folk can audit open source whereas we all have to take the word of private companies who are constantly reducing headcount and replacing devs with AI when it comes to closed source.
Somewhat of a different take from what I've seen from the other comments. In my opinion, the main reason is this:

Companies have basically two reasons to do safety/security: Brand image and legal regulations.
And they have a reason to not do safety/security: Cost pressure.
Now imagine a field where there's hardly any regulations and you don't really stand out when you do security badly. Then the cost pressure means you just won't do much security.
That's the software engineering field.
Now compare that to open-source. I'd argue a solid chunk of its good reputation is from hobby projects, where people have no cost pressure and can therefore take all the time to do security justice.
In particular, you need to remember that most security vulnerabilities are just regular bugs that happen to be exploitable. I have significantly fewer bugs in my hobby projects than in the commercial projects I work on, because there's no pressure to meet deadlines.
And frankly, the brand image applies even to open-source. I will write shitty code, if you pay me to. But if my name is published along with it, you need to pay me significantly more. So, even if it is a commercial project that happens to be published under an open-source license, I will not accept as many compromises to meet deadlines.
It's because anyone can find and report vulnerabilities, while closed source could have some issue behind closed doors and not mention that data is at risk even if they knew
Zero day exploits, aka vulnerabilities that aren't publicly known, offer hackers the ability to essentially rob people blind.
Open source code means you have the entire globe of developers collaborating to detect and repair those vulnerabilities. So while it's not inherently more secure, it is in practice.
Exploiting four zero-day flaws in the systems,[8] Stuxnet functions by targeting machines using the Microsoft Windows operating system and networks, then seeking out Siemens Step7 software. Stuxnet reportedly compromised Iranian PLCs, collecting information on industrial systems and causing the fast-spinning centrifuges to tear themselves apart.[3] Stuxnet's design and architecture are not domain-specific and it could be tailored as a platform for attacking modern SCADA and PLC systems (e.g., in factory assembly lines or power plants), most of which are in Europe, Japan and the United States.[9] Stuxnet reportedly destroyed almost one-fifth of Iran's nuclear centrifuges.[10] Targeting industrial control systems, the worm infected over 200,000 computers and caused 1,000 machines to physically degrade.
Stuxnet has three modules: a worm that executes all routines related to the main payload of the attack, a link file that automatically executes the propagated copies of the worm and a rootkit component responsible for hiding all malicious files and processes to prevent detection of Stuxnet.
Wikipedia - Stuxnet Worm
- “Open source code means you have the entire globe of developers collaborating to detect and repair those vulnerabilities.”
  Heartbleed has entered the chat
- The whole Stuxnet story is fascinating. A virus designed to spread to the whole Internet, and then activate inside a specific Iranian facility. Convinced me that we already live in a cyberpunk world.
It's not more secure or less secure, but it is easier to trust
The idea you're getting at is 'security by obscurity', which in general is not well regarded. Having secret code does not imply you have secure code.
But I think you're right on a broader level, that people get too comfortable assuming that something is open source, therefore it's safe.
In theory you can go look at the code for the foss you use. In practice, most of us assume someone has, and we just click download or tell the package manager to install. The old adage is "With enough eyes, all bugs are shallow". And I think that probably holds, but the problem is many of the eyes aren't looking at anything. Having the right to view the source code doesn't imply enough people are, or even meaningfully can. (And I'm as guilty of being lax and incapable as anyone, not looking down my nose here.)
In practice, when security flaws are found in oss, word travels pretty fast. But I'm sure more are out there than we realize.
- It's also easier to share vulnerability fixes between different projects.
  "Y" was using a similar memory management as "T", T was hacked due to whatever, people that use Y and T report to Y that a similar vulnerability might be exploitable
  Edit:
  In closed source, this might happen if both projects are under the same company.
  But users will never have the ability to tell Y that T was hacked in a way that might affect Y
By your logic no one can break locks because they can't see it. There are going to be people trying to break into everything even tho they don't have the source code.
9/10 people looking into your code are the ones using it for themselves, so fixing a bug for everyone is beneficial to them too.
Also, there are entire companies working and sponsoring these projects and paying people to find bugs because if someone finds out that curl has a problem, they are gonna have that too, so the only difference between something like vlc and adobe is that you don't have to suck their dick really.
There's also curl and others which are offering bug bounties, since they are way more cost efficient than paying someone full time.
Otherwise, you need to be some kind of freaking retro-engineering expert.
And as it turns out, there is a ton of financial motivation for less than ethical people to develop those skills and use them to hack proprietary software. And there is some, but less, financial motivation for ethical people to do the same.
Assumed by who?
It helps hackers sure, but it also help the community in general also vet the overall quality of the software and tell the others to not use it. When it's closed source you have no choice but to trust the company behind it.
There's several FOSS apps I've encountered, looked at the code and passed on it because it's horrible. Someone will inevitably write a blog post about how bad the code is warning people to not use the project.
That said, the code being public for everyone to see also inherently puts a bit of pressure to write good code because the community will roast you if it's bad. And FOSS projects are usually either backed by a company or individuals with a passion: the former there's the incentive of having a good image because no company wants to expose themselves cutting corners publicly, and the passion project is well, passion driven so usually also written reasonably well too.
But the key point really is, as a user you have the option to look at it and make your own judgement, and take measures to protect yourself if you must run it.
Most closed source projects are vulnerable because of pressure to deliver fast, and nobody will know until it gets exploited. This leads to really bad code that piles up over time. Try to sneak some bullshit into the Linux kernel and there will be dozens of news article and YouTube videos about Linus' latest rant about the guilty. That doesn't happen in private projects, you get a lgtm because the sprint is ending and sales already sold the feature to a customer next week.
Per Eric S. Raymond "many eyes make all bugs shallow".
Basically it's not inherently more secure, but often it's assumed that enough smart people have looked at it.
But yes all software is going to have vulnerabilities
Its relatively easy. First of all if someone would implement a backdoor its much easier to find out, since you can look at the code directly. Second is, that a lot of people actually do this. Looking at the code of projects and searching for ways to find security holes in it.
So even if it isn't that much more secure than closed source, its much easier to trust simply because people can search for vulnerabilities much easier.
One great example of why open source code is easier to realise backdoors would be the xz Security breach.
It doesn’t literally mean that everyone that uses OSS will inspect the source code for vulnerabilities, most don’t even have the skill to do so.
It’s more secure because access to source facilitates exploiting it, and patching it, faster, and because nerds that do have the skills and find something unusual will delve into the code to debug it. The XZ Utils back door was found by one of such nerds doing beta testing, it didn’t even get to be distributed to general users.
It’s a telling sign that malicious actors nowadays are surreptitiously trying to compromise OSS through supply chain attacks instead of directly finding zero days. For example: StarDict sends X11 clipboard to remote servers
- Xz is such a great example of how open source is more resilient, and how much "core open source" project need a foundation supporting them
Isn't that actually also helping hackers?
Evil hackers don't need help and don't want help.
On the other side, there have been cases where evil programmers have brought malicious code into open source software, and it got found out because that code is public, and it got repaired and reported publicly.
Shame on these hackers.
- I don't think you'll get much shame out of hackers. Most are incorrigible trolls or politically motivated (and occasionally both); their moral centres are non-existent or aligned very differently.
  You might get an apology from the odd individual who was on the cusp of growing up anyway, but everyone else is a dead loss.
Exactly. Open source means by design there are more people able to look at the code and therefore more emphasis for those interested in the code to want to make sure it works securely. You can be exploitative and try to keep your hack secret but there's also a chance that someone else will see the same thing you saw and then patch the code with a PR. Granted it depends on how much the original developer cares about the code to begin with to then accept or write in a patch/fix for the vulnerability that someone else brings up but the example software you listed are larger projects where lots of people have a vested interest in it working securely. For smaller projects or very niche software that have less eyes and interest, open source might not be the most secure.
On the closed source side, the people who are interested in looking for hacks are the ones who are much more motivated to actually exploit vulnerabilities for personal gain. The white hat hackers on the other hand for closed source software are fewer because not having the code available openly means they have to have more motivation (ie the company offering bounties/incentives because they care about security) to actually try to work out how the closed source software works.
Ape alone... weak. Apes together... strong.
- Now I’ve got an image in my head of apes sitting around in the jungle using laptops
  
  GibbonHub
  
  Fixing back door exploits multiple code repositories 😂
Because more eyes spot more bugs, supposedly. I believe it, running closed source software is truly insane
If you want to see the source code of Photoshop, you actually need to work for Adobe. Otherwise, you need to be some kind of freaking retro-engineering expert.
What you're describing is known as "security through obscurity", the practice of attempting to increase security of a system by hiding the way the system works. This practice is highly discouraged, as it is known to not actually be effective at increasing the security of a system.
Security by obscurity alone is discouraged and not recommended by standards bodies. The National Institute of Standards and Technology (NIST) in the United States recommends against this practice: "System security should not depend on the secrecy of the implementation or its components."
https://en.wikipedia.org/wiki/Security_through_obscurity#Criticism
Isn't that actually also helping hackers?
No, by sharing the implementation details of the system, it helps those trying to keep it secure by allowing anyone to inspect, discover, and contribute fixes to security flaws.
Open-source software is not perfect and is suceptible to security flaws and vulnerabilities, but it is better and more secure than closed-source software in every way. Every risk that applies to open-source software also applies to closed-source software, but worse.
Helping hackers is the whole point. They can read the source code and report problems with the software.
In addition to the other good points -
OpenSource software allows you to create reproducible builds in theory. Such that you can take the source code provided by the vendor (which you theoretically audit to ensure you are satisfied it takes no unexpected action or whatever your concerns are) and compile it, and get something that can be validated as 100% identical to what you get if you buy the compiled version from the vendor directly.
Without this assurance, the vendor can tell you that this thing they sold you does XYZ, but unless you are looking for it in your network traffic for example you might not know it's uploading webcam pictures of you in the background to ihackedyourwebcam.com or collecting and transmitting telemetry you didn't agree to or etc. Or you don't realize that software you installed on your server has a hardcoded hidden administrator user with password 123456, etc etc etc.
Also, while Linux in particular is by no means perfect, as a Linux user I know I'm using software that is much more likely to be also used by people who WILL take the time to inspect the code themselves, or might take the time to audit what it does on their network, or any of a bunch of other things that bring hard to quantify additional layers of security to the ecosystem around FLOSS.
Exploits in a lot of closed source software are from really stupid/simple things they’d get ridiculed for if the code were open.
In other words, I think being open creates “pressure” for code to be presentable and auditable. That, and there’s tons of opportunity and incentive for dysfunction with closed source stuff, like sitting on known exploits.
…That being said, it isn’t universal. Is a lone hero dev maintaining some open library going to be more effective at security coverage than a huge commercial team? Probably not.
Does the software for nuclear bomb security need to be public? Probably not.
If Adobe-or-Whatever has an undisclosed vulnerability, a few hundred people could easily already know about it due to working there. It can be due to bugs, or intentional backdoors required by corporate HQ or government.
They will leak this information. Either by accident or for financial gain. Those people will re-sell it to other shady people.
Now you sit on software where an unknown number of third parties can hack your shit. And you don't know about the vulnerability, what is at risk, how to protect yourself, or who from.
You can mostly trust corpos to protect against general hackers to some extent, but backdoors by government or from their own needs they will just keep secret.
Sony's Rootkit fuckery is probably the biggest example I can give, but there are tons more. Anti-piracy software are historically frequent offenders.
Your post is similar to one I saw some time ago. That old post has a reply of mine, and I’ll paste it here:
The problem you’re describing (open sourcing critical software) could both increase the capabilities of adversaries and also make it easier for adversaries to search for exploits. Open sourcing defeats security by obscurity.
Leaving security by obscurity aside could be seen as a loss, but it’s important to note what is gained in the process. Most security researchers today advocate against relying on security by obscurity, and instead focus on security by design and open security. Why?
Security by obscurity in the digital world is very easily defeated. It’s easy to copy and paste supposedly secure codes. It’s easy to smuggle supposedly secret code. “Today’s NSA secrets become tomorrow’s PhD theses and the next day’s hacker tools.”
What's the alternative for the military? If you rely on security by design and open security for military equipment, it’s possible that adversaries will get a hold of the software, but they will get a hold of software that is more secure. A way to look at it is that all the doors are locked. On the other hand, insecure software leaves supposedly secret doors open. Those doors can be easily bashed by adversaries. So much for trying to get the upper hand.
The choice between (1) security by obscurity and (2) security by design and open security is ultimately the choice between (1) insecurity for all and (2) security for all. Security for all would be my choice, every time. I want my transit infrastructure to be safe. I want my phone to be safe. I want my election-related software to be safe. I want safe and reliable software. If someone is waging a war, they’re going to have to use methods that can actually create a technical asymmetry of power, and insecure software is not the way to gain the upper hand.

43 comments