Batu69 Posted November 16, 2016 Share Posted November 16, 2016 Security concerns are the main reason why most companies and startups are hesitant to use open source software (OSS) in their projects. When part of a project’s code is open, it seems vulnerable to security threats and more likely to be copied. In this article we’re going to debunk some common myths about the security of open source solutions. 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 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. Article source Link to comment Share on other sites More sharing options...
Security concerns are the main reason why most companies and startups are hesitant to use open source software (OSS) in their projects. When part of a project’s code is open, it seems vulnerable to security threats and more likely to be copied. In this article we’re going to debunk some common myths about the security of open source solutions. 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 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. Article source
Recommended Posts
Archived
This topic is now archived and is closed to further replies.