The Security of Open Source: The benefit of the process-enabled community

Note: Here’s another guest post from our friends at Black Duck, specifically Phil Marshall. Phil brings over 10 years’ experience in both product and services marketing as well as over a decade of experience in the high-tech publishing space with publications including Dr. Dobb’s Journal and Byte magazine. Prior to joining Black Duck, Phil was Director of Global Solutions Marketing at Ness Software Product Labs, a division of Ness Technologies. Before Ness Technologies, Phil held product marketing positions at both RSA and Sun Microsystems and was Director of Marketing at Compliance Engineering, a healthcare focused Systems Integration firm.

Lasse Andresen, CTO of ForgeRock recently wrote an article for SC Magazine in which he makes a great case for the relative security of open source software.   That same month, Lucian Constantin, a writer for IDG News Service, published an article in PC World in which he describes vulnerabilities found and reported in seven popular open-source projects, indicating that there’s plenty of room for improvement when it comes to the security of open source projects.  Can they both be right?

I’d argue that yes, they are both right.  But  to reconcile these assertions, we need to take a closer look at each perspective.

Lasse, to support his argument that open source software is more secure, lists four key observations regarding the use of open source. For enterprise users of open source, the takeaways are:

• Open source is “enterprise-ready.”  With companies like Google, Amazon, Red Hat, and SugarCRM as heavy users and supporters, it’s hard to believe that organizations would not consider open source enterprise-ready.
• Open source is great for developers AND great for IT operations.  Choosing quality components results in “production stability, no interruption in service, the guarantee of quality assurance testing and patches, and controlled and frequent upgrades.”
• Not just anyone can contribute, and review processes exist.  Lasse states that “in a commercial open source environment, each member goes through an approval process after which they are provided with the appropriate credentials.  After this, they are able to commit code, but the code then goes through a sophisticated process of review, acceptance and rejection.  The end result is thoroughly tested enterprise-ready software.”
• Responsibility for failures and ongoing maintenance is born by hundreds of companies.   Hundreds, maybe thousands of companies use open source code within their products.  Because of this use, they’re automatically responsible for what they’re licensing to customers.   And the collaborative nature of open source development leads to quick releases of product updates, fixes, patches and new versions.

Lucian, in his article, reports on a test of the presence of security flaws in popular distributed open source applications.  While a limited test of seven applications, including:

• Moodle, a web-based learning/course management system that has been downloaded over 4.7 million times from SourceForge;
• vTiger, a Web-based customer-relationship-management system with over 3.6 million downloads;
• Zabbiz, a software product for monitoring network and application performance in enterprises with almost 3 million downloads;
• ISPConfig, a web-hosting control panel for Linux servers with 1.5 million downloads;
• OpenMediaVault, an OS distribution based on Debian Linux for network-attached storage servers with over 700,000 downloads;
• NAS4Free, a network-attached-storage server OS based on FreeBSD with over 600,000 downloads; and
• Openbravo ERP, an open-source enterprise resource planning (ERP) product with 2.1 million downloads all hosted on SourceForge.net, six out of seven applications  allowed remote-authenticated hackers to execute commands on the underlying operating system, and in the seventh, the researcher found an XXE (XML eXternal Entity) vulnerability that could allow an attacker to read arbitrary files from the file system.

Conducted by Rapid7 and Brandon Perry, an application security engineer and regular contributor to the Metasploit penetration testing framework, the test included contacting each project with their findings.  A small sample to be sure, Rapid7 reported that only three of the projects patched the issues reported to them, and, just as alarming, Rapid7 reported that common industry vulnerability report best practices were not followed.

While the article states that large open source developers like the Apache and Mozilla foundations have good processes in place for dealing with vulnerability reports, there’s room for improvement.

Let’s agree they’re both right.  Lasse is right.  Open Source can be more secure.  Lucian is right.  While open source can be more secure, it demands the same security best practices as its proprietary software cousins, especially for projects that are distributed.  The good news is that consumers of open source can put policy, process, and technology solutions in place that can make everyone successful, from the developer attempting to accelerate the development of high quality software by incorporating open source projects, to the IT operations professional concerned about maintenance and support.  Before using an open source component, developers can quickly learn about version, commit history, number of committers, and whether projects are foundation driven – all important risk factors to consider.

While not all open source is enterprise-ready,  it benefits from the OSS community model and with some scrutiny and due-diligence up front using readily available resources like ohloh.net, organizations can select  open source projects that are, in fact, enterprise-ready. Overall, communities and end-users of OSS must take the same approach to security best practices that security-conscious ISVs do when writing proprietary software solutions.