Open Source Code Contains Security Holes -- Open Source -- InformationWeek

[gem at cigital.com (Gary McGraw)]

Good points Ken.

I lurk on a top-secret open source list that has been discussing this since New Years.  I posted an entry on Justice 
League with my partially formed opinion:
http://www.cigital.com/justiceleague/2008/01/09/on-open-source/

I have also written a longer piece, which will be posted one of these weeks on darkreading.

The gist of my opinion is that these open source projects are excellent work that should be commended, but that focus 
exclusively on bugs.  Coverity's PR has been straightforward and correct, but the press does not get it.

For example, compare these two articles:
http://www.informationweek.com/story/showArticle.jhtml?articleID=205600229&cid=RSSfeed_IWK_All
http://www.zdnet.com.au/news/security/soa/11-open-source-projects-pass-security-health-check/0,130061744,339284949,00.htm

There's a /. thread on this to:
http://slashdot.org/article.pl?sid=08/01/09/0027229

gem

company www.cigital.com
podcast www.cigital.com/silverbullet
blog www.cigital.com/justiceleague
book www.swsec.com

-----Original Message-----
From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org] On Behalf Of Kenneth Van Wyk
Sent: Thursday, January 10, 2008 8:18 AM
To: Secure Coding
Subject: [SC-L] Open Source Code Contains Security Holes -- Open Source -- InformationWeek

SC-L,

I imagine many of you have seen the results of Coverity's DHS-funded scan of a *bunch* of open source projects:

http://www.informationweek.com/story/showArticle.jhtml?articleID=205600229&cid=RSSfeed_IWK_All

The stats are interesting, I suppose.  I don't see any prioritization of the defects, but I imagine those were provided 
to the various open source project leaders.

The question that isn't addressed here, and I'm sure was well outside of the scope of the project, is what each open 
source project *did* with the vulnerability information BEYOND just fixing the bugs?  Did they merely fix the problems 
and move on?  Or, did they use the defects as an opportunity to educate their team members on how to avoid these same 
sorts of things from creeping back in to the src tree?  If they simply treated the vul lists as checklists of things to 
fix, then I'd expect a similar study in (say) five years to be just as bad as the recent Coverity study.

I think it's important to learn from mistakes, not just fix them and get on with things.  I sure hope the open source 
teams in this study did some of that.  If any SC-Lers have insight here, please share.

Cheers,

Ken

-----
Kenneth R. van Wyk
SC-L Moderator
KRvW Associates, LLC
http://www.KRvW.com