Open-source versus proprietary software Is one more reliable and secure than the other?

IBM Systems Journal,  June, 2005  by A. Boulanger

• E-mail
• Print
• Link

Software defect levels

Software defects are a fact of life, and any software package, whether FOSS or proprietary, is likely to have a substantial number of flaws. A percentage of these defects will directly impact the security of the system. According to the Software Engineering Institute, an experienced programmer produces approximately one defect per 100 lines of code, or an average defect rate of 1 percent. (10) If, during the software development life cycle, 99 percent of those defects are discovered and remedied, then approximately 1000 software defects will remain in a software package consisting of one million lines of source code, a modest code base by current standards. For example, the Red Hat Linux ** 7.1 distribution consists of approximately 30 million lines of code (LOC), and Microsoft Windows ** XP contains approximately 40 million LOC. Even with extensive testing and defect remediation, there will still remain a very significant number of software defects in these systems. Using the defect rate statistics noted earlier, Windows XP and Red Hat Linux would be estimated to have approximately 40,000 and 30,000 undiscovered defects respectively. In addition, both proprietary and FOSS systems are constantly evolving. As they progress through the software life cycle, features are added to the system and defects are discovered and remedied. Because most software packages are in this constant state of evolution, it is difficult to estimate the number of software defects a particular system will contain. When code is added to a system, there is also the possibility that the developers will introduce a new defect into the system. There are even examples where a developer has produced modifications to correct one security problem but inadvertently introduced another. Software defects can even occur due to problems having nothing to do with changes in the source code. For example, there have been instances where a defect in a development tool has introduced a defect into a system build.

Software defects are an unavoidable problem that can reduce the overall reliability of a system. When the reliability of a system is reduced, the overall security of the system is also reduced. Reliability and security are inextricably intertwined. A highly reliable system has fewer software defects and, in general, is more secure than an unreliable system. To use an analogy from the physical world, a padlock built with an excellent locking mechanism (security) but constructed with defective steel (a defect) offers very little security. The same is true for a lock using excellent construction materials (security), but having a defect in the locking mechanism (reliability) that makes the lock vulnerable. A classic example of the latter involved the published demonstration that a particular high-security bicycle lock could be quickly opened with an ordinary Bic ** pen. (11)

Every software package release, whether FOSS or proprietary, contains a number of defects. The available data suggest, however, that when a software flaw is discovered, the FOSS community responds more rapidly than proprietary software vendors. According to an article published by e-Week Labs, FOSS organizations in general respond to problems more quickly and openly, while proprietary "software rendors instinctively cover up, deny, and delay." (12) The FOSS organizations produce small fixes that are available publicly through mailing lists and Web sites. Users of the affected software can download the update, apply the patch, and rebuild the system. The patch itself is in turn a segment of source code that is available for inspection by the general public. In contrast, proprietary software vendors tend to wait and roll out large cumulative releases known as service packages. These service packages usually contain only binary code, which is not open for public scrutiny and can potentially introduce new problems into the system. The users of proprietary software products must blindly trust the integrity and competence of the software publisher; whereas, FOSS users know that the patches they have installed can be (and will be) publicly scrutinized.