Security is an integral part of your Microservices architecture. Due to many services at play in a Microservices application, the exploitable surface area of the application is higher than traditional applications. It is necessary that organizations developing Microservices adopt the Microsoft Security Development Lifecycle (SDL).

Using the SDL process, developers can reduce the number of vulnerabilities in software while shipping it using agile methods. At its core, SDL defines tasks which can be mapped to the agile development process. Since SDL tasks do not realize functional objectives, they don't require a lot of documentation.

To implement SDL in conjunction with agile methodology, it is recommended that SDL tasks be divided into three categories:

1. Every sprint requirements: The SDL tasks in this category are important to implement therefore they need to be completed in every sprint. If these tasks are not completed, then the sprint is not deemed complete and the product cannot ship in that sprint. A few examples of such tasks include:
   • Run analysis tools daily or per build
   • Threat model all new features
   • Ensure that each project member has completed at least one security training course in the past year

2. Bucket requirements: The SDL tasks in this category are not required to be completed in every sprint. The tasks in this category are categorized into multiple buckets, and tasks from each bucket may be scheduled and completed across sprints. An example of such a classification is as follows:
   • Verification tasks: This category includes mostly fuzzers and other analytics tools and may include tasks such as BinScope analysis, ActiveX fuzzing, and so on
   • Design review tasks: This category includes tasks such as privacy reviews, cryptography design reviews, and so on
   • Response planning: This category includes tasks such as defining the security bug bar, creating privacy support documents, and so on

Note that the number of tasks in the various categories may vary across projects and therefore need to be uniquely tailored for each project that is undertaken.

3. One-time requirements: These requirements need to be met only once in the lifetime of the project. These requirements are generally easy and quick to complete and are generally carried out at the beginning of the project. Even though these requirements are short and easy to accomplish, it may not be feasible to complete the requirements within an agile sprint as the team needs to deliver on functional requirements as well. Therefore, a grace period is assigned to each task in this category within which each task must be completed, which may vary depending on the complexity and size of the requirement. A few tasks that this category includes are adding or updating privacy scenarios in the test plan, creating or updating the network down plan, defining or updating the security bug bar, and so on.