The main reason why most companies and startups doubt if to use open source software (OSS) in their projects is security. The code of a product with an opened code seems to be more vulnerable for threats and more liable to making copycats or stealing innovations and thus provides enough reasons to refuse from OSS. We decided to take a deeper look at this question and help people seeking answers make final decisions.
1. Anyone can read an open code and take advantage of security bugs found.
While this statement in general makes sense, the situation in the real life is much more complicated.
First, if we’re talking about popular and established open source tools and solutions (like Linux OS, Apache web server, Ruby programming language), the communities around them are extremely huge, which in turn leads to a growing amount of eyeballs looking at the code and checking it for flaws. On the contrary, the proprietary product teams usually have a very limited number of people assigned to provide and check the necessary security level.
Second, the product security itself is something that you can provide by following general yet reliable techniques. The easiest one is to perform security tests that will check the most common found vulnerabilities in the code, like incorrect user rights settings, absence of data encryption algorithms, improper use that might lead to unexpected behaviour, etc. Usually in the open source projects the new code is not even released to public until all potential security vulnerabilities are found and fixed.
Finally, if compared to proprietary tools, open source software at least provides you with the transparent info on its security, while the paid software offers you no other option except believing the vendor. With OSS you can also take part in code review and then either to stick with the previous version, release your own patch or even disable the functionality under suspicion via code until further notice.
2. No business interest means no motivation to make OSS secure enough.
Actually, many successful open source products has become profitable for the teams behind it. For instance, Mozilla gets significant part of revenue from Firefox for user click-throughs on search page ads, a few Linux distributives are offered for enterprises with paid support, etc. Most of such projects have their own security response teams created specifically for patching the vulnerabilities.
In case of non-profitable open source tools, when the vulnerability is found, the open source project team will usually either immediately fix it (since their reputation is at stake), or disclose the issue publicly so that all could take corresponding measures — say, switch off the vulnerable functionality or set other hardware and software to avoid using the affected functionality.
In the meanwhile, businesses can keep critical vulnerabilities unnoticed for years and when found quickly fix it through a planned patch like nothing happened. For instance, in August 2015 Microsoft has issued patch that fixed the critical vulnerability found in Internet Explorer starting from version 7, which was released back in 2006. All the following versions also had the same security hole that let an attacker run malicious code remotely.
Also, if we’re speaking of motivation, each participant of the OSS community is motivated to bring the high-quality product with no major flaws to prove its competence, while businesses are often limited in so many ways (money, time, business objectives, etc) that there is always enough reasons to limit the amounts of security assurance work. For open source such motivation results in a more thorough development process with less vulnerabilities in public releases.
3. Still, open source nature of the code brings additional security threats to products
Actually, any nature of the code brings security threats to any product. More important question is what kinds of security threats it brings, and proprietary tools won’t answer this question, unlike OSS.
If talking more specifically, in the end it’s the developers that make the open source code insecure, but this happens due to a number of mistakes like:
- what’s not following the security guidelines
- what’s improperly working or setting the software up for the goal set
- what’s using easy passwords
- what’s lack of data validation processes
- what’s absence of data encryption techniques, etc.
But in case of extremely popular open source tools that can’t happen due to strict guidelines and a huge number of people that will thoroughly review the code after it is written.
And keep in mind that if needed, you can always additionally enhance the security of an open source product thanks to its open source nature.
So what, open source software is more secure than proprietary tools?
Does all the above-mentioned means that any open source software is more secure due to its nature? Of course, no. Moreover, sometimes the open source code is simply not enough reviewed due to the very small community of its users. Or, on the contrary, many people can look into code and miss a critical vulnerability, since the sole ‘looking at code’ doesn’t guarantee its security. So in every single case you should take your own look at the way the software of your choice is protected and its reputation.
First, you can always search and review its version history and previous security issues. Maybe you will also find an independent agency stating that it's secure, or certificates proving its reliability, or a fellow developer of yours who will ensure that it's the best option on the market.
Second, see what kinds of tools your competitors, partners, established companies in the industry are using. For instance, Ruby on Rails is used by 500px and Airbnb, and that’s a great indicator that this framework is reliable enough for use in startups.
Finally, it may appear that the best option for you is proprietary software or a mix of both kinds of tools (which is also a popular approach taken by Facebook and Google, for instance). The most important thing here is to make a well-considered decision based on the checked info and refuse from outdated biases. As people say, forewarned is forearmed.