Security Through Obscurity - Open Source Repercussions

Open Source Repercussions

Software which is deliberately released as open source once experienced a security debacle in the late 1980s; for example, the Morris worm of 1988 spread through some obscure — though widely visible to those who looked — vulnerabilities. An argument sometimes used against open-source security is that developers tend to be less enthusiastic about performing deep reviews as they are about contributing new code. Such work is sometimes seen as less interesting and less appreciated by peers, especially if an analysis, however diligent and time-consuming, does not turn up much of interest. Combined with the fact that open-source is dominated by a culture of volunteering, the argument goes, security sometimes receives less thorough treatment than it might in an environment in which security reviews were part of someone's job description.

On the other hand, just because there is not an immediate financial incentive to patch a product, does not mean there is not any incentive to patch a product. Further, if the patch is that significant to the user, having the source code, the user can technically patch the problem themselves. These arguments are hard to prove. However, research indicates that open-source software does have a higher flaw discovery, quicker flaw discovery, and quicker turn around on patches. For example, one study reports that Linux source code has 0.17 bugs per 1000 lines of code while non-Open-Source commercial software generally scores 20-30 bugs per 1000 lines.