The debate is endless—proponents of free (open source) software and proprietary (closed source) software are fighting it out on mailing lists, Usenet, personal flames, advertisements, and Websites. The question—which gives better security as a generic model of software development, open source or closed source software?

The immediate reaction (may I call it knee-jerk) to this question is, "If it’s open for scrutiny, then it can’t be secure, since anyone can go through the source code and find out potential exploits." Yes, it does look that way. At least until we try to separate the facts from the myths.

Myth 1

Since anyone can examine free software source code, anyone can find security holes and exploit them.

Absolutely true. Anyone can examine the source code, look for (and perhaps find) security holes and exploit them.

By the same token, anyone could also examine the source code, find potential holes, and report them to the author. Experience says that the number of "good guys" examining any given source code is much more than the number of black hats. It follows that the chances of a hole being found and fixed far outstrip the chances of a hole being found and exploited.

For example, a number of buffer overflows were found in various Linux programs, arising from the use of an insecure function (strcpy). These were quickly fixed using a secure version (strncpy), before any significant exploits of these holes could be made on the Internet. In addition, hundreds of other software packages (which hadn’t been demonstrated to be insecure) were examined and all strcpy’s replaced with their secure versions, much before anyone thought of trying to exploit them.

Myth 2

Since free software explicitly comes with no warranty, there’s no incentive for the authors to fix security holes quickly or effectively.

At the very least, a statement like this shows a serious lack of understanding of the free software development model. Many papers have discussed what drives a person to make free software, and while we don’t have the bandwidth to discuss this in detail, a couple of motivations stand out starkly—peer recognition and creativity. Programmers write free software because they’re innately creative people, and for many, their day jobs are unable to channelize that creativity. Another driving factor is peer recognition, where recognition that comes to you as an author of good software is worth its weight in gold.

Given these, it follows that free software authors are extremely interested in ensuring that their products are kept updated and bug-free as far and as soon as possible.

This is borne out by numerous examples. To take just one, when the infamous "teardrop attack" was first launched in 1997, Linux and FreeBSD fixes were available within a few hours of the attack becoming widespread. Contrast this with proprietary operating system vendors, who took from two weeks to forever to come out with a fix. To quote one network appliance vendor, "There’s no fix scheduled for this. The device is more secure when used on a secure network protected by a firewall."

Which brings us to...