Grass roots secure coding efforts

["Kenneth R. van Wyk" <Ken () KRvW com>]

Greetings all,

One of the things that I hear most from software developers when I deliver 
secure coding tutorials and such is that they're likely to be unable to do 
things like detailed threat modeling, risk analyses, etc.  The reason most 
often cited is that they're under tight deadlines and there's not enough time 
in the schedule for such activities.  

Of course, to really expect any sort of culture shift, there would need to be 
top-level support for adopting secure coding practices.  That said, I often 
spend some time brainstorming lists of things that the students can consider 
trying by themselves as soon as they are back in their offices.  I'm talking 
about "grass roots" sorts of activities that won't break the bank (or 
schedule) here.

Some of the things that the students have suggested include the following:

- Informal peer review of code modules
- Incorporation of (usually free) static code review tools in the code reviews
- Setting up an information sharing site/portal/drive internally for 
developers to load useful links, tools, experiences, etc.
- and so on

Most often, the students agree that these sorts of things are the types of 
simple first steps that they could reasonably expect to take.  Anyone here 
have other suggestions on other first steps that developers might consider, 
even in the absence of top-level embracing of a more secure development 
methodology?

(No, I'm not suggesting that a simple list like this be any sort of substitute 
for a more in-depth program, but it's a starting point for developers to 
experiment with in trying to improve the security of their software dev 
practices.)

Cheers,

Ken van Wyk
-- 
KRvW Associates, LLC
http://www.KRvW.com