Open-source software is now seen in more than half of enterprises, and its use is only growing according to new research from Fortify Software and Larry Suto. The new report details the testing of eleven popular open-source products used in enterprise, and outlines the risks that they pose.
Open-source security gets a shake down in recent report. (IMG:Open Source)
The study validates that open-source software (OSS) development communities have yet to adopt a secure development process and often leave dangerous vulnerabilities unaddressed. Additionally, the study found that nearly all OSS communities fail to provide users with access to security expertise to help remediate these vulnerabilities and security risks.
The thing to remember here, and this is for both OSS advocates and those against the OSS development community, is that the study comes from a security vendor that tests software for vulnerabilities. This does not invalidate its findings; however, it does one good to remember that just because a report highlights a weakness does not mean it is the end of the world, or that companies using the “vulnerable” technology are hopelessly open to attack. Likewise, it is silly to assume that because you use open-source technologies, you are instantly secure.
The study, sponsored by Fortify Software and completed by application security consultant Larry Suto, examined Derby, Geronimo, Hibernate, Hipergate (a CRM Web application), JBoss Application server, Jonas Application server, OFBiz, OpenCMS, Resin, Struts, and Tomcat.
[Note: Fortify products as well as manual scanning were used to test the security of the eleven products. Fortify tested two to four versions of each project .]
Some of the findings in the report include little-to-no access to security information (documentation or direct URL link), security experts, or e-mail contacts for security-related questions or reporting. Only Tomcat had access to all three, with Resin and JBoss offering access to an expert -- with JBoss offering security documentation as well.
However, the others are all community supported. One interesting note was that JBoss is listed as having no prominent security e-mail alias. One would assume that the expert that was located for the research was Anil Saldhana, whose e-mail is clear on most of the security documentation on the JBoss issue tracker (Saldhana also runs the JBoss security blog that is located by reading documentation and the Wiki).
Other problems located, for example XSS or SQL Injection (SQLi), were listed as a “daunting challenge for open source developers.” The counts were 22,828 for XSS vulnerabilities, and 15,612 for SQLi.
"Fortify, through the Java Open Review (JOR) project, has worked with over one hundred open source development teams to identify common classes of security vulnerabilities, including Cross-Site Scripting and SQL Injection," offered the report. "However, many open source development teams have not leveraged JOR, causing them to lose a key opportunity to quickly identify and remediate security issues."
The numbers of XSS and SQLi vulnerabilities are high, yes; however, there is no breakdown of these vulnerabilities by release version. So some of the updates to the various software packages might have corrected these issues. While not the exact scope of the research, it would have been nice to see.
OSS projects operate on a community scale. While it is true that they should implement security throughout the development process, not all projects will have the sheer number of coders to test and implement security and users to locate and report bugs. Each of the eleven products tested are all community driven, and there are people who look at security issues within the project. Some projects fail to have a single security team or person simply because no one person on the project has a single job.
Is this a failing of open source? Yes, in a way it is, open source wants to tap into the mainstream and get more than a 'fan base' level of usage, to do this it has to play by corporate rules. However, most of the suggestions offered by Fortify in its paper are already seen in the larger open-source projects.
“Open source projects should adopt robust security practices from their commercial counterparts,” is one example outlined by the report. Apache, MySQL, and PHP, are all open-source projects you will see in commercial applications. Each one of them has a security team, and each of those teams works with and independently of the respective development teams.
As Fortify mentioned in its report: “The projects included in this study were selected because they are implemented in Java (the most common programming language for enterprise development), represent a wide range of application functionality, and are used extensively to build and deploy enterprise applications.”
This test was legit, as long as companies who read it remember that the test looked at Java-based projects only. The final recommendation of, “Government and commercial organizations that leverage open source should use open source applications with great caution,” is misleading and will cause some to assume all open source is lacking with security (and you will see this in news articles surrounding the Fortify research).
Assuming an open-source application is secure simply because it is open source is, once again, foolish. However, there is more of a security mentality in much of the open-source community because they are perfectionists. Some projects often see several bug fixes a month, most due to reports from the community at large and from the users of the project itself (MySQL for example, or the various distro releases in Linux used in IT).
There is one thing the Fortify research makes clear, which rings as very true: No one layer of security is going to protect you. Applications will come with flaws, some are old, and others will be discovered next year. Whether you use closed source or open source on your network, you have to maintain your own security policy and layers. This includes making sure the open-source software you use is actively maintained, and updated.
Comment on this Story