I recently received a warning, reporting that a popular program has yet another security problem because of a buffer overflow. I had to laugh, thinking back to Microsoft CEO Steve Ballmer's retort, "You would think we could figure out how to fix buffer overflows by now."
Criticism of these software problems and recent acts of terrorism has many organizations, including Microsoft, rethinking security and software development as part of the processrather than an afterthought. Unfortunately, in organizations that do not have a good record of keeping discipline among the programming staff, adding such protective measures may not be easy.
The popular image of the programmer is the nerdy-type person with high-caffeine soda cans piled in the cubicle, churning out code that dazzles everyone. Standards? The programmer knows better than those out-of-date standards committees. Documentation? Programmers do not do documentation; programmers write code. Tell him what you want and the programmer will magically make it happen, even if he has to stay up all night, every night, for the next three weeks.
These attitudes are difficult to change, but not impossible. However, as the manager or director of a programming shop, you need to add information assurance to the programming task. Consider developing policies and implementing them in increments, using my top four rules for secure development (described shortly).