This appears to be the hot topic these days, with Bill's Memo and all.
Rafael F. Ferreira
Security is an emergent property. Therefore I think it needs to be an explicit design goal, just like any other piece of functionality.
Seems to me that it comes down to people. People write software and people are fallible. Fortunantly, people can be trained. Problem is the american collage system does a damn lousy job of it when it comes to security and/or quality. Want secure code? Turn out people that understand _how_ to build secure code (training), that are motivated to create secure code (compensation schedule), and work in a culture that promotes quality in all it's aspects, not just the quality of "security" as some ethereal goal. I've acutally taken collage courses an at a top 10 CS school in the US where I was _discouraged_ from writing good code over writing code quickly. So long as it worked for the test case...
I think that programmers need help from their APIs to write secure programs. The most common security bugs are well-known, such as buffer overruns, running a program with root permission, or writing files to the /tmp directory. Bad APIs, like gets() or strcpy(), need to be replaced with secure functions such as strlcpy(). New APIs should be created that help programmers to common things, such as writing temporary files or needing root permissions, in a more secure manner. Unix, in particular, seems to be afraid to introduce new APIs or remove deprecated APIs like gets().
Fog Creek Home