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