Every organization that develops software or write scripts should embrace security development lifecycle (SDL). However, it remains a rare practice. That's a shame, because developing software with fewer security bugs better protects users and data for less money.
SDL is not just for full-time developers. I frequently document in enterprise assessments that the admin scripts and tiny programs created by network and infrastructure teams are among the most insecure software I find. They're often in folders readable by the entire network of users or they contain a gambit of vulnerabilities. Even worse, I often spot hard-coded admin passwords within the code.
[ Master your security with InfoWorld's interactive Security iGuide. | Stay up to date on the latest security developments with InfoWorld's Security Central newsletter. | Get a dose of daily computer security news by following Roger Grimes on Twitter. ]
All companies should implement formal SDL programs and processes within their internal programming and scripting groups. The following contains some guidance to help get you started.
Ready, set, learn
Begin first with SDL training. You'd be surprised by how many programmers haven't been taught the basics of threat modeling and secure programming techniques. A simple Internet search will reveal dozens of books and courses on SDL. Microsoft, my full-time employer, recently published a free white paper on the subject. The company is also one of SDL's most vocal proponents and offers additional information on the subject through the Microsoft website, in the Security Development Lifecycle blog, in MSDN Magazine, and in a book from Microsoft Press on the subject by Michael Howard and Steve Lipner. Other good sources on SDL include SANS and the SEI (Software Engineering Institute).