Open Source Code = Insecure Code?

Research released by application security vendor Fortify (www.fortify.com) in July 2008 has highlighted
security flaws in commonly used open source applications, some of which are being
installed and deployed by large enterprises and government organisations.

The paper, “Open Source Security Study – How are Open Source
Development Communities Embracing Best Security Practices?” reports on research
undertaken by Fortify into the security of open source projects.

A range of projects were examined ranging from the Derby
relational database through to the JBoss application server and the OpenCMS
content management server. The projects were analysed using Fortify SCA, a
static analysis tool used to detect security flaws in software code. Any major
security issues identified by the tool were then checked manually to confirm
the finding.

Flaws were uncovered that spanned two or three generations
of product, showing a lack of attention for up to 1 year. Across the range of projects analysed, issues
per 1000 lines of code (KLOC) ranged from 0.27 through to 178.2. Cross site
scripting and SQL injection class attacks were prevalent and clearly still show
that developers are missing these code security problems.

Conclusions from the team at Fortify focus on the need for
organisations to treat open source with care ensuring that any installed code
has been checked for security flaws. They also urge open source developers to
take care with their development and undertake robust security testing of any
code being developed.

The report was interesting from a number of perspectives.
First, it provides some empirical data to suggest that open source software can
contain security flaws, as does commercial software. Clearly this is a report
from an application security vendor so any evidence like this is bound to be
tied up with special interests but it says what it says. But any sensible,
objective observer would suggest that open source software is just as prone to
software code security flaws as commercial software (or vice versa) as we are
all capable of making mistakes. I guess what it does highlight is the need to
maintain development hygiene within a software development lifecycle and
methodology that supports productive coding which is also secure, whether you
are writing open source or proprietary.

Quality of code has been a mantra shouted by both sides of
the open vs. proprietary debate, with both parties able to point out the flaws
of the others’ products. Of course there are very many large
organisations and governments that have deployed open source solutions which
are tight as a drum from a security perspective. Likewise there are others that
have done the same with proprietary solutions.

Sure, it would be fascinating to take a cross section of
proprietary applications in the same class as those examined and see if the
issues/KLOC were just as prevalent. I would guess, with little effort, one
could quite easily select some ghastly proprietary applications and demonstrate
terribly insecure code.

So where does this Fortify study leave us? I come away from
it unsurprised, but hoping that it can be used by sensible CISOs and CIOs to
offer some balance to the often venomous rants undertaken by both extreme sides
of the proprietary vs. open software debate.

The report can be accessed from here.