Security through popularity
The
popularity of the Microsoft Windows operating system on the desktop and
Internet Explorer as a Web browser is often cited as a reason for the rate of
vulnerability discovery and exploits. There is some truth to that. For a closed
source, proprietary operating system or Web browser, it is certainly true that
greater popularity would tend to bring greater attention from writers of
malicious code and other undesirables. Things change when introducing a whole
new development model in which popularity is a key factor, however.
With open source software, there is a very low bar to entry for adopting a given piece of software. Because open source software is not necessarily encumbered by any price tag at all, in our increasingly networked world a new operating system installer can be had for no more than the cost of a blank writable compact disk and a few minutes for the download. Depending on your installation method, even the price of the CD can be avoided.
The ease of widespread adoption of open source software adds to the ease of attracting new developers to an open source software project as well. As users increase in number, so too do programmers with an interest in the project. The developers from open source software are drawn from the pool of users, and in addition to this open source software makes good use of casual interest amongst programmers who do not have the time to devote to serious development team involvement, but can easily spare a few minutes now and then to search for, and fix, vulnerabilities and other bugs.
As a result, the number of people looking at a popular piece of open source software for vulnerabilities and other bugs to fix is disproportionately large when compared with closed source software with a limited developer base. That number increases as the number of users increases, as well. The people finding new vulnerabilities for purposes of exploiting them are vastly outnumbered by those finding new vulnerabilities for purposes of fixing them and, even when the people finding the vulnerabilities do not themselves write the code to fix them, they report their findings to people who will do so.
The consequences of this state of affairs are clearly visible, as the fastest recorded Microsoft vulnerability patch distribution after the vulnerability's existence became public knowledge was the WMF library patch earlier this year, with a turn-around time of "approximately nine to 10 days" according to Debby Fry Wilson, the director of the Microsoft Security Response Center. Meanwhile, the Mozilla Foundation routinely produces, tests, and releases patches for the Mozilla Firefox Web browser in less than a week, and patch times for the Linux kernel are often measured in hours rather than days.
This is in large part due to the wide distribution of labor for patch testing: as Debby Fry Wilson said when discussing the WMF patch's quick release, what takes a long time is testing -- not patch development. It simply isn't reasonable to expect closed source software to keep up without the ability to test as widely, and often to receive fixes from the testers themselves when testing runs into problems, considering the open source development community's access to a cast of thousands of testers rather than dozens at best.
Proprietary software need not apply
Proprietary
software vendors such as Microsoft are beginning to investigate the feasibility
of harnessing some of the social forces at work in providing these benefits to
enhance the security of their proprietary software offerings. They're
discovering that there are some distinct hurdles in their path, however, that
appear at this time to be insurmountable. Even the most liberally conceived
methods of achieving similar benefits, such as making source code publicly
viewable and offering new versions and patches for public testing in unlimited
distribution, fail to create the same positive environment for security through
visibility that is enjoyed by open source software.
The reason for this is simple: the user base does not have the same investment in the software itself. It is "someone else's software", and they cannot be assured that the future development of the software will serve anyone's needs aside from those of the vendor. The potential loss of any invested time and effort in the software's development and improvement, due solely to the whim of the vendor is a strong disincentive for involvement.
Visibility vs. Obscurity
The
open source development community relies on a distinctly different philosophy
of software security from that required by a closed-source, proprietary
development model. Obscurity can serve security concerns for proprietary
software vendors by keeping vulnerabilities out of the public eye long enough
for their programmers to develop patches, which safeguards market share by
creating a public image of security, even though this can often lead to periods
of widespread vulnerability without software users being aware they are at risk.
Open source software development provides benefits to visibility that more than
make up for any potential security losses incurred, and provides knowledge to
software users that they can use to protect themselves until a patch is
available. These benefits cannot ever be fully harnessed by proprietary
software.
Though the question of visibility versus obscurity as a security characteristic is not the only factor determining software security, it is an important one to understand when examining the open source philosophy of software development, and when analysing the security characteristics resulting from these two very different software development methodologies.
TechRepublic is the online community and information resource for all IT professionals, from support staff to executives. We offer in-depth technical articles written for IT professionals by IT professionals. In addition to articles on everything from Windows to e-mail to firewalls, we offer IT industry analysis, downloads, management tips, discussion forums, and e-newsletters.
©2006 TechRepublic, Inc.
1%
1%
Whilst Microsoft source code is very guarded, it is available to view for many customers and government organisations, so the view it is closed is not totally true, just selectively visible but not updatable.