GuidesDo More Eyeballs Mean More Secure Code?

Do More Eyeballs Mean More Secure Code?




One of the basic theories behind open source and its relative security is
the fact that many eyeballs are looking at code to identify potential and real trouble spots.

Not necessarily. Fortify Software has released a research report alleging that open source software developers are leaving the ramparts unprotected.

Discuss this article in the ServerWatch discussion forum

Unsure About an Acronym or Term?
Search the ServerWatch Glossary

 

However, according to application security vendor Fortify Software, many eyeballs
alone aren’t enough. In fact Fortify argues in a new study that open source
software is insecure and is exposing enterprises to risk since secure
development processes have not been properly adopted.

Fortify’s study ran 11 open source Java projects through
a barrage of tests to identify secure practices. The
projects were: Derby (relational database),
Geronimo (app server), Hibernate (object relational mapping tool), Hipergate
(CRM web application), JBoss Application server,
Jonas Application server, OFBiz E-Business solution web application,
OpenCMS Content management solution, Resin Application server, Struts Web
application framework and the Apache Tomcat app server.

In general, Fortify found projects had a variety of security vulnerabilities, including cross-site scripting (XSS) and SQL injection flaws, as well as an overall lack of
secure development processes in place.

“We think that open source software is an area of under-explored risk that
we want to help enterprises better understand it,” Jacob West security
research group manager at Fortify told InternetNews.com. “We found
notable vulnerabilities in all of the 11 open source packages we looked
at. Because of the rampant numbers we found, we think that open source
projects aren’t leveraging security tools properly.”

West added that most of the projects examined did not make security experts readily available to their users. He argued there was also a lack of secure mechanisms for reporting and dealing with bugs.

Fortify has a degree of motivated self interest in open source Java
security. Since 2006, Fortify has run the Java Open Review
(JOR) project
, which used Fortify’s static source code analysis tools to
identify bugs. Fortify claims they’ve worked with more than 100 open
source projects to date to help them improve their code. West claimed that
so far JOR has found about 389 confirmed defects, and approximately 357 have
been fixed as a direct result.

Surprisingly, Hibernate, Ofbiz, Struts and Tomcat — four of the 11 projects Fortify noted were already part of JOR prior to the new Fortify study.

Sometimes tools aren’t enough

West argued that sometimes tools alone are not enough, and projects
need to take it on themselves to fix issues and to bake security in as part
of the development process methodology.

“The main message coming from the report is around the lack of process and
the need for building security in,” West said.

In West’s view, on the commercial proprietary side large organizations have
begun to adopt secure development processes and they do things like risk
assessment up front and really make security key at every step of
development.

“All the evidence we’ve seen on the open source side is that that revolution
hasn’t begun yet for open source security,” West said.

West then noted there are exceptions. He cited a new effort from Mozilla with its Security Metrics tracking of how effective Mozilla’s security is overall. But he also noted it’s not a new secure development effort from a pure coding perspective.

“The first step they have taken is to evaluate their security, that’s true,”
West admitted. “Making that available publicly and doing it in a fairly
visible way is a really good first step.”

Overall, according to West, a secure development process don’t necessarily fit in
any one particular place within a development cycle. There are however critical
areas that Fortify has identified in its report that are key, among them is
the need to cultivate human expertise around security.

“In particular Microsoft blazed this path of having a security lead someone
who is within the development organization and whose primary responsibility
is security and that’s critical,” West argued. “That’s not happening in open
source projects today.”

Additionally West commented that security needs to be built into the
development process using threat modeling and code review technology.

Other studies in the past from vendors like Coverity have shown open source
software to have fewer
defects
than proprietary alternatives. Coverity which also does source
code analysis was also the recipient of a Department of Homeland Security
(DHS) grant in which the
overall bug count of 250 open
source projects were reduced. Outside of the DHS grant, Mozilla has also
been a Coverity customer since 2006 to reduce software
defects in the Firefox code base.

Fortify’s West did not debate that other efforts at open source code
analysis exist however he argued that overall there needs to be more of a
commitment from open source developers for secure development processes.

“The real goal here is to raise awareness both within the enterprise
community that is leveraging open source and the developers themselves,”
West said. “I feel strongly that we have gone about this in a responsible
way and we are not calling attention to specific deficiencies in specific
projects. I can’t predict what the open source community will say about this
report but we’re making our best effort to improve the situation through
calling attention to it and actively contributing to it through Java Open
Review.”

This article was originally published on InternetNews.com.

Latest Posts

Related Stories