Developer Forums | About Us | Site Map


Useful Lists

Web Host
site hosted by netplex

Online Manuals

Secure programmer: Developing secure programs
By David A. Wheeler - 2004-01-21 Page:  1 2 3 4 5 6

Will FLOSS make us secure

Free-Libre/open source software programs are those with licenses that give users the freedom to run the program for any purpose, to study and modify the program, and to redistribute copies of either the original or modified program (without having to pay royalties to previous developers). Synonyms include open source software (OSS), "Free Software" (FS) when capitalized, and OSS/FS. "Free Software" and "open source software" can be used interchangeably for the purpose of this article, but "FLOSS" is preferred since it embraces both terms.Typical FLOSS programs are developed by communities of developers, working together and reviewing each other's work. The Linux kernel is FLOSS, as is the Apache Web server and many other programs; FLOSS is becoming increasingly popular in many market niches.

A FLOSS program's source code is available for public review, and there's been a raging controversy about how that affects security. Will FLOSS be more secure because of all the public scrutiny that's possible? Or, will FLOSS be less secure because attackers have more information -- making it easier to create attacks against the program?

The answers are starting to come in, and they're more nuanced and complicated than simple claims like "FLOSS is always more secure." There's certainly evidence that FLOSS can be more secure than proprietary software. For example, the FLOSS OpenBSD operating system has had far fewer vulnerabilities reported than Microsoft Windows. But there's a reasonable counter-claim: since there are more Windows users, perhaps Windows is attacked more often, meaning that Windows vulnerabilities are more likely to be found. It's very doubtful that that's the whole story, but it shows how hard it is to make equal comparisons.

A better example is the Apache Web server: it's far more popular than Microsoft's proprietary IIS Web server, yet Apache has had fewer serious vulnerabilities than IIS. See my paper "Why OSS/FS? Look at the Numbers" (in Resources) for more statistics about FLOSS, including security statistics.

It's also clear that attackers don't really need source code. Just look at all the Microsoft Windows exploits available! More importantly, if attackers needed source code, they could use decompilers, which recreate source code that's good enough for attacking purposes.

But the answer also isn't simply "FLOSS is always more secure." After all, you could change a proprietary program's license to FLOSS without changing its code, and it wouldn't suddenly become more secure. Instead, there are several factors that appear necessary for FLOSS programs to have good security:

  • Multiple people have to actually review the code. All sorts of factors can reduce the likelihood of review, such as being a niche or rarely-used product (where there are few potential reviewers), having few developers, using a rarely-used computer language, or not really being FLOSS (such as a "shared source" license). If every code change is examined by multiple developers, this will usually aid security.

  • At least some of the people developing and reviewing the code must know how to write secure programs. One person can help train others, but you have to start somewhere.

  • Once a vulnerability is found, the repair needs to be developed and distributed quickly.

In short, the most important factor in whether or not a program is secure -- whether it's FLOSS or proprietary -- is whether or not its developers know how to write secure programs.

It's perfectly reasonable to use a FLOSS program if you need a secure program -- but you need to evaluate it in some way to determine if it's secure enough for your purposes.

View Secure programmer: Developing secure programs Discussion

Page:  1 2 3 4 5 6 Next Page: Figuring out your security requirements

First published by IBM developerWorks

Copyright 2004-2023 All rights reserved.
Article copyright and all rights retained by the author.