I wanted to let you know that the Microsoft Security Development Lifecycle team has just announced a new offering that makes writing secure code easier! This morning they released the Microsoft SDL Process Template for Visual Studio Team System. This new template is designed to work with TFS 2008.
For several years, security has been a top priority here at Microsoft. All of our software products use the SDL process to design and build with security in mind. Using the SDL has significantly improved the security and privacy of our products and reduced the number and severity of software vulnerabilities – protecting our customers.
By taking advantage of Visual Studio Team System, the SDL team has put together a solution that reduces the barrier to entry for SDL adoption, provides auditing for satisfying the security requirements, and helps demonstrate security return on investment.
Let me run through a few screen shots to highlight how the SDL Process Template addresses many common concerns for security champions, developers, testers, and even management.
For security champions
With the SDL Process Template, a security owner can easily tackle that initial question of “where do I start”? The Process Guidance page provides a security owner (and the entire team) with a brief overview of the SDL, five steps for Getting Started on an SDL project, and details on customizing the template and extending it for third party security tools. There is even more material supporting SDL implementation and customizing the SDL Process Template in the SharePoint library.
Below: The SDL Process Guidance “front page”
A security owner can accelerate the task of defining security requirements by opening up a query that includes all of the default SDL requirements – ready to triage and assign! There is also a custom work item to add your own requirements or recommendations.
Below: all SDL Requirements and Recommendations pre-loaded and ready to triage
Developers care about security, but they want it to be intuitive. The SDL Process Template includes check-in policies that will ensure every checkin of code is taking advantage of the SDL required compiler/linker flags and Code Analysis features already in Visual Studio. This will eliminate entire classes of security weaknesses from your code!
Below: Setting Check-in policies
Below: Check-in policies in action
Testers want to be able to emphasize the importance of a security bug and properly communicate the impact to their product. The default “bug” work item now has customized security fields so you can identify security severity, and security cause/effect (using STRIDE), and mark a bug as “Blocking” or “Not Blocking.” This feature allows you to track and search for security-specific bugs.
Below: Identifying a bug as a security issue
The management team wants an easy-to-read document that summarizes the security work completed. The Final Security Review Report and Security Bugs Report provide an auditable set of artifacts that details security work completed as well as deferred tasks.
· Page One: status of all bugs marked as Security Bugs
· Page Two: completion status for the SDL Requirements and Recommendations
· Page Three: security bugs found by all tools integrated with the template
Below: Page 1 of the Final Security Review
I think the SDL Team has done a great job building a custom process template to address the challenge of making your code more secure. I would encourage you to go check it out and start making security a priority in your new team projects!