Appendix T: SDL-Agile Frequently Asked Questions
Q: Can teams release products without ever having to complete some requirements?
A: Yes, but it is not the intent of SDL-Agile to allow teams to ignore or avoid certain SDL requirements indefinitely. This is a side effect of a process that is designed to respect the needs of the team to spend a significant amount of time innovating and implementing new features while still maintaining an appropriate security baseline. No requirement can go more than six months without being completed (or having an exception granted).
Q: Why not mandate a round-robin or other type of requirement rotation to ensure that all requirements eventually get addressed?
A: Some teams feel strongly that certain requirements are a better use of their limited time budget. If, for example, a team feels that the process of running and analyzing attack surface analyzer results is not as valuable as running and analyzing file fuzzer results, it can perform file fuzzing more often and attack surface analysis less often.
Q: Why not mandate a security spike-a sprint totally focused on security?
A: If teams want to do this, great! But it is not part of the SDL-Agile requirements. In general, one of the guiding principles of SDL-Agile is to keep teams from spending so much time on security that it significantly affects their feature velocity. A mandated security spike would definitely affect a team's feature release schedule.
This documentation is not an exhaustive reference on the SDL process as practiced at Microsoft. Additional assurance work may be performed by product teams (but not necessarily documented) at their discretion. As a result, this example should not be considered as the exact process that Microsoft follows to secure all products.
This documentation is provided “as-is.” Information and views expressed in this document, including URL and other Internet website references, may change without notice. You bear the risk of using it.
This documentation does not provide you with any legal rights to any intellectual property in any Microsoft product. You may copy and use this document for your internal, reference purposes.
© 2012 Microsoft Corporation. All rights reserved.