Open source software security issues: How to review OSS for security

Ask the Expert

Open source software security issues: How to review OSS for security

There are many security tools available from the open source community, and I’d like to take advantage of them in my organisation. Is it safe for me to trust open source software? What are some potential open source software security issues?

Continue Reading This Article

Enjoy this article as well as all of our content, including E-Guides, news, tips and more.

Open source software (OSS) is computer software for which the source code and various other rights are available in the public domain. With the current economic situation putting businesses and government departments under increasing pressure to reduce costs, the appeal of OSS over traditional, proprietary software products continues to grow. Not only are OSS products typically free, they have an inherent flexibility that closed source software (CSS) does not, because users and developers have access to the source code and the freedom to change it.

Case studies
of trouble-free real world deployments are of more value than claims 
of how 
many times 
a product 
has been 
downloaded.

The security of open source software versus closed source software products is a highly emotive topic, with proponents on both sides vigorously arguing their viewpoint. The main case for OSS being the more secure approach to creating software is summed up in Linus' Law, which states, "Given enough eyeballs, all bugs are shallow". Put another way, given a large enough beta tester and developer base, almost every problem and fix will be obvious to somebody.

However, just because a program’s source code is available doesn’t mean it has been thoroughly reviewed for weaknesses. Moreover, security vulnerabilities are not the same as bugs. Bugs are found when software doesn’t do what it is expected to do. Complete security is only achieved when the software does what it is expected to do in all conditions, so testers have to actively create unexpected conditions to find vulnerabilities.

While there are no statistics or surveys that prove whether OSS or CSS is inherently more secure, there are three areas you can investigate to determine if an OSS product will be sufficiently secure.

1.  Look at the development team.
When considering an OSS product, look for a company or development team that has a proven track record of delivering quality products and issuing patches quickly once a vulnerability has been discovered. Many of the larger, well-established products within the OSS community (such as Apache) are well-managed with sound change-control processes that easily stand up to or surpass those of some well-known commercial software vendors.

There are some open source projects that are not well supported and lack robust processes, similar in many ways to some smaller or less security-conscious companies making commercial software. Opting for a product from a lesser known or less experienced team or company means you are taking a security risk with the product.

2.  Look at the user community.
Be sure to consider the user base when evaluating an OSS product for security. Look for a mature community with a clear policy about how contributions are evaluated and included, and a reliable regime in place to handle errors or problems. Case studies of trouble-free real-world deployments are of more value than claims of how many times a product has been downloaded.

3.  Look at the documentation
The quality of the product’s documentation is also an important consideration. How easy is it to find relevant information? Are there third-party specialists who can be hired to provide support? Don't get caught up with promises of lifetime support from a company or project that has only been in existence for a few years; development and support can be discontinued at any time. You only have to look at consumer experiences with white goods to know that vendors can come and go, disappearing overnight and leaving behind all guarantees, spare parts and promises of help.

This was first published in February 2012

 

COMMENTS powered by Disqus  //  Commenting policy