Open Source Software Security

1. Anyone can read open code and take advantage of bugs

While open source code can be read and compromised in principle, in practice the situation is much more complicated.

First, according to expert opinion, people who break software don’t actually need to look at the source code. For an experienced developer there’s no need to dig into thousands of lines of code to find a vulnerable piece. So why do people claim that open source code is insecure?

In reality, any kind of code (closed source or open source) brings security threats to a product. Ultimately, it’s developers who make open source code secure or insecure; insecurities arise due to a number of mistakes such as:

• not following security guidelines
• improperly setting up software
• using easy passwords
• lack of data validation processes
• absence of data encryption techniques

The second reason why the situation is more complicated in practice is because the fact that anyone can read code actually increases your chances of finding and fixing bugs. Open source projects, as a rule, have vibrant communities that continuously support them and check them for flaws. Also, developers care about their reputations, and want to show off code that’s written in accordance with best practices and want to find and fix potential security vulnerabilities.

2. No financial incentive means no motivation to make OSS secure

Actually, many successful open source products have become profitable for the teams behind them. For instance, Mozilla gets a significant part of the revenue from Firefox for user click-throughs on search page ads. Most projects of this caliber have their own security response teams dedicated to patching vulnerabilities.

In the case of open source tools that aren’t profitable, when a 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 those implementing the code can take appropriate measures — for example, switching off the vulnerable functionality or setting other hardware and software to avoid using the affected functionality until it’s fixed.

As far as the motivation to develop open source software is concerned, each individual developer in the OSS community is motivated to offer a high-quality product with no major flaws in order to prove their own competence. On the other hand, businesses are often limited in many ways (money, time, business objectives, etc.), and thus may actually limit the amounts they invest in product security. Because open source developers are personally motivated to work on the projects they select, the result is a thorough development process with fewer vulnerabilities in public releases.

3. Proprietary software is inherently more secure than open source software

This myth comes from many prejudices. But a commercial licence doesn’t guarantee security. Unlike proprietary software, open source projects are transparent about potential vulnerabilities. With paid software you simply have to trust the vendor. With an OSS security you can also take part in code review and then either stick with the previous version, release your own patch, or even disable certain functionality under suspicion until further notice.

At the beginning of this article we mentioned the benefit of large number of people working on open source projects: they’re more likely to find and fix bugs quickly. On the contrary, proprietary software teams generally consist of fewer people, and don’t always include necessary specialists, such as QA engineers, who help eliminate vulnerabilities.

So is open source software actually more secure than proprietary software?

Is open source software inherently more secure? Of course not. You need to look at the security and reputation of each piece of software on an individual basis.

To investigate the security of a product, you can always review its version history and look at previous security issues. Maybe you’ll even find an independent agency vouching for a product’s security, or certificates proving its reliability, or a respected colleague who can assure you that it's the best option on the market.

Additionally, you can see what tools your competitors, partners, and established companies in the industry are using. For instance, Ruby on Rails is used by 500px and Airbnb, and that alone is a great indicator that this framework is reliable enough for startups.

It may be the case that the best option for you is proprietary software, or perhaps a mix of proprietary and open source tools (a popular approach taken by Facebook and Google, for instance). What’s important is that you make your decision based on research and avoid making decisions based on biases.