Why do Programmers Write Insecure Code?

Secure Programming for Linux and Unix HOWTO
Prev | Chapter 2. Background | Next

# 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.).

Prev | Home | Next
Security Principles | Up | Is Open Source Good for Security?