As a setup for this column, you might want to first read Jeremy Dallman's "'Crawling' Toward SDL" post, which can be found on the Security Development Lifecycle (SDL) blog. You will notice that the concepts in this column map very well onto Jeremy's ideas and will allow you to add more structure and precision to your security efforts as you learn to crawl, then walk, and finally run with the SDL.

What I am proposing is using the threat model to help drive other SDL security requirements, primarily code review priority, fuzz testing priority, and attack surface reduction. That's all there is to it. Of course, I need to explain myself, so let's look at each in a little detail. Let me start with threat modeling."

"In my opinion, when people think of security vulnerabilities, most think of implementation bugs. One could argue that the SDL is focused a little too much on implementation bugs, and historically it was because most of the vulnerabilities Microsoft has fixed resulted from implementation bugs. But over the last couple of years we have moved more resources to focus on secure design, in part because the implementation bugs are now more scarce thanks to the SDL.