Is Open Source Development Insecure?

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.
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

Fortify’s study looked at 11 open source java projects and ran them through a barrage
of tests to identify secure practices. In general Fortify argued that the projects had a
variety of security vulnerabilities including Cross Site Scripting and SQL injection
flaws and that there was 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 “We found notable vulnerabilities in all of the
eleven 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 across the projects they examined most did not make security experts
readily available to their users. He also argued that there was also a lack of secure
mechanisms for reporting and dealing with bugs. The eleven projects that Fortify looked
at include: 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.

Fortify has a degree of motivated self interest in open source Java security. Since
2006, Fortify has run the Java Open Review (JOR)
which used Fortify’s static source code analysis tools to identify bugs.
Fortify claims that they’ve worked with over a hundred 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 though, four of the projects included in the 11 that Fortify now includes
in their new report were actually already part of JOR. Hibernate, Ofbiz, Struts and
Tomcat were all part of the JOR prior to the new Fortify study.

Sometimes tools aren’t enough

West argued that sometimes tools alone are not enough and that the 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. For example, 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 West noted that 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
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.”

Article courtesy of

Latest Articles

Follow Us On Social Media

Explore More