di Vittorio Bertola
In the Internet technology and business world, a question has been hotly debated for at least twenty years: is open source software more or less secure than its closed, purely commercial counterparts?
Supporters of the open source development model will say that open source software is more secure, as it is jointly developed by a community of people that can check each other’s work. Furthermore, each of its users can check the source and discover both unintentional vulnerabilities and intentional backdoors – and even fix them independently.
Open source also shields its users from the risk of changing commercial conditions; no vendor can lock you into ever rising pricing schemes or just make unavailable an application that is vital for you. At most, an open source vendor can stop working on it, but you still have the code to keep it alive and even develop it further.
SEE ALSO: Open source: The next 20 years
Opponents of open source will reply that often the community behind this kind of projects boils down to a couple of overworked, underfunded, distracted developers sitting in a basement, amateur in their approach to software testing and release; and that, in case anything goes wrong, the users of the application will have no one to blame (or to sue).
Also, while you can actually scrutinize and enhance the code, this is not what you usually do when you choose a piece of software; checking line by line the code of a big application is a daunting task that only makes sense in very special cases, such as military uses; and if the open source project you rely upon dies by resource starvation, you may not want to continue investing in it anyway.
Another point of discussion relates to whether the full transparency on an application’s code makes it more or less secure. This issue, however, seems to be settled for good; almost everyone agrees that “security by obscurity” is not a great idea. Even the most secret and valuable pieces of information end up being exposed sooner or later, usually by mistake, through social engineering, or via other non-technical tricks. Thus, security should be intrinsic in the design, and not rely on any secret in the code, but only on credentials (passwords, keys, etc.) that are not part of the code and can be secured more easily and changed when necessary, and on well-known and tested algorithms.
SEE ALSO: Security vulnerabilities in open source and GDPR implications
Moreover, if there are vulnerabilities that can be immediately detected by looking at the code, opening the source code up makes them much more likely to be intercepted quickly. Other bugs and vulnerabilities are not discovered by looking at source code, but rather through routine tests and corner case experiments, and specific applications such as interactive disassemblers; in this case, the availability of the source code does not make any difference.
Finally, the security of any algorithm should not rely on its secrecy, but on sound logical and mathematical premises. Actually, formal security analysis – describing a software algorithm or protocol through symbols, and analyzing the security of such an abstract model – is an increasingly popular way to detect problems. To this purpose, withdrawing the logic of your software from public scrutiny is actually counterproductive; relying on public, widely confirmed best practices and research results is much better.
Is open source more secure?
So, what is the bottom line: is open source software more or less secure than commercial applications? The actual answer is that open source has some security advantages over closed source, but in the end, the availability of the code is not the primary factor that determines the security of an application.
What really makes a difference in the security of an application is how carefully this security is being designed, tested, and kept up to date by those who make it; how many resources are invested in it; how important it is considered by the development team.
You can find very secure or very insecure applications in both worlds, so you should look carefully for trusted software makers in both of them. Sure, there still is a significant difference: open source software makers show you their code and bet their face on it, while, for closed source applications, you have to rely only on the maker’s word. Corporate priorities and legal assessments may even push a closed source software maker to hide or ignore a known security risk in their code, something which is much harder to do with open source software (and even in that case, someone else could find it and fix it for you).
