Open source code has fewer flaws, but there is a catch

0


[ad_1]

Open source code is of lower quality than proprietary code. At least, that’s how a lot of people see it now.

Until this year, you could make a compelling argument that flaws in freely available source code are more likely to be spotted and fixed quickly than flaws in proprietary software. Then came Goto Fail, Heartbleed, Shellshock and Poodle. These four high-profile bugs in open source software have gone undetected and fixed for years, in some cases, although the code has been freely available to anyone.

That was enough to put a question mark back in the minds of many people about how open source software is developed – and whether it is enough to rely on someone, somewhere, to analyze the code and spot. faults. There is a risk that everyone will assume that someone else is analyzing the code when, in fact, no one with the right skills is actually doing it. This calls into question the wisdom of adopting open source software in the enterprise.

[ Survey: Security, Quality Top Companies’ Reasons for Using Open Source ]

But proprietary software frequently contains flaws, including security vulnerabilities. Is there any real evidence to suggest that open source code is better or worse than its closed source equivalent?

The Coverity Annual Analysis Report provides a source of objective information on the number of code flaws in open source and proprietary software. The report analyzes the levels of defects found in software developed using the two different models, which it runs through its static analysis system.

It is important to keep in mind that the scan report only includes software submitted for analysis; in a sense, this is a self-selected sample. That said, it turns out that the defect density – the number of bugs per 1,000 lines of code – in open source and proprietary software is broadly similar.

In fact, the most recent report (2013) found that open source software written in C and C ++ had a lower defect density than proprietary code. The average defect density on projects of all sizes was 0.59 for free software and 0.72 for proprietary software.

Applications with few lines of code had, in general, lower defect densities than larger ones, although large applications with more than one million lines of code actually had a lower density than some applications of code. midsized.

Open source code can be secure, but fewer teams protect it

This seems to give open source software an endorsement when it comes to code quality. When it comes to security bugs in particular, however, many open source projects are taking inadequate steps to prevent them, according to Zack Samocha, senior director of products at Coverity.

“A typical proprietary software company will have a security team that will make sure best practices are followed. They have the budgets to maintain these teams, ”he said. “I don’t see these entities… in the open source community. “

[ Feature: Why Open Source Software Isn’t as Secure as You Think ]

This may be true for small projects, but open source commercial companies such as Red Hat, as well as many large open source projects, especially those with software intended for enterprise deployment, almost always have a concerted security effort.

Samocha says the Linux community is taking action to increase security – although there is still a lot to do, in his opinion – but adds that all open source projects need to add security to their daily thinking. “In commercial software vendors, developers and CIOs think about security all the time. In open source projects I’m not sure this happens.

Samocha also believes that open source projects could make better use of the ecosystem around existing security and business tools. “The majority of the tools are aimed at security teams rather than developers,” he says. “Security teams should filter out flaws and give the developer community the relevant ones to fix. “

Help with static analysis tools, but only to a limited extent

Of course, projects that don’t have a security team can’t work this way. Individual developers running analysis tools may be overwhelmed with too many irrelevant bugs or false positives. This can lead them to ignore these tools altogether.

“If developers have to waste precious cycles investigating too many ‘I don’t care’ results, or if they spend too much time waiting for the scan to complete, they will inevitably stop using these tools,” says Jon Jarboe, senior technical director. at Coverity.

Security teams are also helpful because while code execution through static analysis tools can detect many code flaws, it almost certainly won’t detect all of them.

The Heartbleed bug is a good example: At the time, Coverity’s static analysis would not have detected it until it was discovered. (The company added a new scan heuristic that now detects this, but that’s not the point.) The Shellshock bug is another: some static scan tools would have detected it, but only with a large number of issues that would have turned out to be false positives.

“Static analysis can find known vulnerabilities. What about unknown vulnerabilities? Asks Mike Gualtieri, senior analyst at Forrester Research. “This is where threat modeling comes in. This technique allows you to find threats to your application and identify mitigation strategies for each of those threats.

If in doubt, check your code

Such a holistic approach to security can be difficult to achieve in a project with many contributors and no security team to coordinate it. How, then, to improve the level of confidence in free software?

[ Related: 5 Ways to Get Open Source Software Support ]

For companies that decide to use open source code from projects that may not have the resources to devote to security, it is still possible to have the code audited by a qualified person or team.

However, such audits can be expensive and time consuming, so large companies or even industry groups may end up funding these projects for the benefit of the wider user community. Alternatively, crowdfunding audits – of how the TrueCrypt audit has been funded since it closed in May – may become increasingly common.

When it comes to core open source projects, such as OpenSSL, which make up a large part of the software infrastructure on which the Internet operates, the Linux Foundation’s Core Infrastructure Initiative can make a significant difference. Funded by Microsoft, IBM, Google and Dell, it aims to provide resources to help these projects improve their security and pay for external code reviews.

Confidence in open source software has certainly taken a hit over the past few months – but, in the end, it’s worth remembering that all software can contain code flaws. Additionally, there is certainly no evidence that software developed using the open source model is more likely to contain serious flaws than any other type of software.

[ad_2]

Share.

Comments are closed.