2.3. Why do Programmers Write Insecure Code?

Many programmers don't intend to write insecure code - but do anyway. Here are a number of purported reasons for this. Most of these were collected and summarized by Aleph One on Bugtraq (in a posting on December 17, 1998):

• There is no curriculum that addresses computer security in most schools. Even when there is a computer security curriculum, they often don't discuss how to write secure programs as a whole. Many such curriculum only study certain areas such as cryptography or protocols. These are important, but they often fail to discuss common real-world issues such as buffer overflows, string formatting, and input checking. I believe this is one of the most important problems; even those programmers who go through colleges and universities are very unlikely to learn how to write secure programs, yet we depend on those very people to write secure programs.

• Programming books/classes do not teach secure/safe programming techniques. Indeed, until recently there were no books on how to write secure programs at all (this book is one of those few).

• No one uses formal verification methods.

• C is an unsafe language, and the standard C library string functions are unsafe. This is particularly important because C is so widely used - the ``simple'' ways of using C permit dangerous exploits.

• Programmers do not think ``multi-user.''

• Programmers are human, and humans are lazy. Thus, programmers will often use the ``easy'' approach instead of a secure approach - and once it works, they often fail to fix it later.

• Most programmers are simply not good programmers.

• Most programmers are not security people; they simply don't often think like an attacker does.

• Most security people are not programmers. This was a statement made by some Bugtraq contributors, but it's not clear that this claim is really true.

• Most computer security models are terrible.

• There is lots of ``broken'' legacy software. Fixing this software (to remove security faults or to make it work with more restrictive security policies) is difficult.

• Consumers don't care about security. (Personally, I have hope that consumers are beginning to care about security; a computer system that is constantly exploited is neither useful nor user-friendly. Also, many consumers are unaware that there's even a problem, assume that it can't happen to them, or think that that things cannot be made better.)

• Security costs extra development time.

• Security costs in terms of additional testing (red teams, etc.).