Do a quick search on secure development and you’ll find pages and pages of advice and best practices. You could relatively quickly create a long checklist of best practices and how-tos covering everything from how to create a threat model to the dos and don’ts of avoiding cross site-scripting mistakes. Newer articles and papers might focus in on applying secure development to mobile applications or making it work in a DevOps environment as the way we have built code has changed over the years.
And yet, despite all we know about creating secure code, many organizations still struggle with making secure development work in practice.
In fact, it’s been a little more than 15 years since Microsoft mandated its Security Development Lifecycle (SDL) in summer 2004. This was two years after the now-famous Trustworthy Computing memo went out and Microsoft began its unprecedented investment of resources into secure software development. But 2004 is a milestone that retains special significance for me and one that holds a lesson often lost in the pages and pages of how-tos and best practices – and has been the key to the SDL’s longevity in a rapidly evolving technology climate – it’s all about the developers. We discovered quickly that focusing on the practices without consideration for how software development is actually done or what developers need to be successful was an effort destined to fail.
To read this article in full, please click here
Support the originator by clicking the read the rest link below.
