Secure Development Lifecycle Process Templates

We’ve been working with the Secure Development Lifecycle team and Microsoft for quite a while now and they’ve done some excellent work to educate customers on how to build secure applications.  They’ve provided some great guidance and tools and made much of it available in a form that works well for Team System customers.

They’ve recently made a series of announcements about their latest round of investments.  They’ve announced the availability of a Beta of a new SDL process template based on the TFS 2008 MSF Agile process template.  This enables customers doing Agile development with TFS to also be able to take advantage of the great SDL practices and integrate it directly into the way they work today.

They also announced that they will be making a TFS 2010 version of the same template available shortly after TFS 2010 releases.

These templates go well beyond just a few new work item fields, reports, etc.  They integrate security tools and processes directly into your workflow.  For example:

• One of the core principles of SDL is that security activities need to take place at every point in the product’s development lifecycle. It would make no sense for MSF-A+SDL projects to contain only a finite list of SDL work items that the team could complete over their first few iterations and then never have to do security work again. If a project lasts for 100 iterations or more, secure development practices should be followed in each and every one of those iterations. To support this requirement, MSF-A+SDL team projects will automatically generate the appropriate new security work items every time a new iteration is added to the project.
• Check-in policies that will verify that code being checked into the project’s source control repository are compliant with SDL development requirements.  These policies can find instances of banned APIs that can lead to privilege escalation vulnerabilities, improperly set compiler or linker options that could increase the potential damage of a successful attack, and other dangerous mistakes.
• The Bug work item has been modified to include Security Cause, Effect, and Origin tracking fields that integrate automatically with the other free tools that the SDL team has already released: the SDL Threat Modeling Tool, the Binscope Binary Analyzer, and the Minifuzz File Fuzzer. Additional reports and filters have been added to the template so that you can easily see which of your security tools are giving you the biggest bang for your buck.
• MSF-A+SDL team projects will also automatically generate new security work items whenever new Visual Studio projects or web sites are checked into the project’s source control repository. These work items will be appropriate to the type of project checked in; for example, adding a C++ Windows library will generate different work items than adding a C# web application will.

Brian