Open Source vs Closed Source Security
There is considerable debate about open source vs closed source security, which is often fueled by biases to one of the different styles of software development. In this article, we will highlight the advantages and disadvantages that are commonly debated in open source vs closed source security discussions to help you draw your own conclusions about which is best.
Advantages and Disadvantages of Open Source Software
The key advantage of open source software is the source code is available for inspection by anyone. That means anyone can check the code to find out if best practices have been followed, and can see for themselves if the coding is sloppy. Importantly, with open source, it is possible to see exactly what the software does. If the source code cannot be checked, there is no alternative other than to trust the developers have been diligent and the company has not incorporated code that performs functions that are hidden from the user.
Many open source projects have large and active communities of users. Vulnerabilities are often identified quickly as many eyes are looking at the code. Since anyone can report vulnerabilities and suggest fixes, any identified vulnerabilities are likely to be fixed quickly. As an added incentive, bug bounty programs often exist which give security researchers a financial incentive for finding – and fixing – vulnerabilities.
Over time, open source projects have the potential to become more secure than closed source software solutions, and well-established projects such as Linux Kernel are considered to be more secure than closed source alternatives simply because so many people are contributing and fixing vulnerabilities.
There are certain caveats with the above arguments. Just because the source code is available for anyone to check, it does not mean that anyone is actually reviewing the code. Anyone looking to incorporate open source code into their own projects will naturally test the code to make sure it works and achieves its purpose, but they may not be checking for vulnerabilities or have the necessary skills to do so. Well-established open source projects with highly active communities of users such as Linux Kernel and Firefox have an army of people checking the code, but that is not necessarily the case for all open source projects.
It is possible that bad actors are looking at the source code to find vulnerabilities that can be exploited, as not everyone has good intentions; however, the reality is there are much easier ways for threat actors to conduct attacks than checking thousands upon thousands of lines of code for vulnerabilities and then developing weaponized exploits.
Contributions could potentially be made to the source code that introduce vulnerabilities, intentionally or unintentionally, and those vulnerabilities could be then pushed out to many users. Generally speaking, while anyone can suggest code changes, only a limited number of people can actually make the changes, and any suggested code changes are likely to be checked prior to being incorporated. Additionally, open source software is usually packaged by a central organization, which ensures the binaries have been obtained from or have been monitored by the open source community.
What are the Advantages of Closed Source Software?
With closed source software solutions, the code is not available for review; so bad actors cannot review the code to identify vulnerabilities. The security of closed source software is somewhat dependent on the source code remaining confidential and that is usually the case. That said, zero-day vulnerabilities are discovered in closed source software and the number of exploited zero-day flaws is increasing – even though the source code is not available for review. It is not necessary to have access to the source code to find exploitable vulnerabilities.
Some open source projects have a huge community of users that check the code, but that is not necessarily the case. Companies that develop proprietary software may, in reality, be checking their code more stringently than is the case with open source projects. Further, the people checking the code are employed by the company that develops the software, and they are likely to have an in-depth knowledge of the product. The quality of proprietary code reviews could consequently be far better that reviews of open source code.
Of course, most software companies will not have an army of employees checking the code. If there are only a few developers, vulnerabilities could potentially exist for many years before they are found. When they are, it can take much longer for security issues to be fixed.
The issue with any open source vs closed source security comparison is that closed source software is a black box. You have no idea whether the code is secure. Even if you don’t have the skills to personally check open source code, you can always pay someone to check it for you. You cannot do that with closed source software. Granted, a company such as Microsoft can recruit highly skilled software developers and will have many processes for checking the code to make sure vulnerabilities have not been introduced, but as the monthly Patch Tuesdays demonstrate, even skilled coders employed by multi-billion-dollar companies can make mistakes.
Summary: Open Source vs Closed Source Security
Studies suggest that when it comes to vulnerabilities in open and closed source software, there is no significant difference in the severity of those vulnerabilities and, generally speaking, it is equally likely for vulnerabilities to be present in open source and closed source software. The main issue is how quickly vulnerabilities are likely to be discovered and fixed and how easy is it for bad actors to find and exploit those vulnerabilities.
When comparing open source vs closed source security it is not possible to say whether one is more secure than another. It is only possible to determine whether open source or closed source is best for security on a case-by-case basis, and even then, there will be advantages and disadvantages with both.