Security Development Life-cycle Approach To Agile Development

In the software development era, many software developing organizations including product and online services, use Agile software development methodologies and principles to build their applications. In the earlier days, security was not considered as the main factor while developing any software. The principle of the Agile methods is to focus on the customer's direct needs. Since security is the main concern for a customer, it is pivotal to look into it.

In today’s IT world, ‘security’ is treated as a major concern to strongly regulate and protect private data. Today, Agile method is recognized as an ‘insecure’ method as it creates unsafe code. This needs to change now. But this can only be changed to reality by integrating security requirements with the Agile development methods.

In accordance to the rising demand, Microsoft has introduced a set of software development process improvement techniques, collectively known as the Security Development Lifecycle (SDL). SDL is considered heavyweight according to the Agile point of view, as it was designed only to secure the large products like Windows and MS-Office, both having longer development cycles. SDL has been capable of removing the vulnerabilities by more than 50% from the shipping software.

How Agile and SDL can be merged?
Combining the two discrete worlds is not a difficult thing. SDL can define the tasks and map these tasks into an Agile development process. If the Agile release cycle is ending within a week, the teams might not get enough time to finish all the SDL requirements for each and every release. Moreover, SDL is designed to manage the security issues, which cannot be ignored easily without reconsidering the size. 

Needs for the SDL and Agile processes-
SDL-Agile process classifies individual Agile requirements based on the frequency of completion into the following three categories.

1. Sprint requirement:
In the first category, the focus should be on achieving all the SDL requirements. Without these, no release can be done. This category is known as the “Every Sprint Requirement”. 
Whether the sprint span is of two weeks or two months, the target must be, to meet each and every SDL requirement in the Every Sprint category, else the sprint will be counted as incomplete, and the software can not be delivered. Some examples of this category are:

• Run analysis tools daily or per build (Apply SDL task to Sprint)
• Use only strong crypto in new code (AES, RSA, and SHA-256 or better)
• Ensure that each team member has gained at least one security training course in the past year

2. Bucket requirements:
In the Bucket requirements, less important tasks are performed lifetime on a regular basis. In this category, the tasks are not mandated for each sprint. Bucket requirements are divided into the 3 buckets of tasks-

• Verification task
• Review task
• Planning task

Teams can choose only one SDL requirement at a time, instead of completing all the bucket SDL requirements for each sprint.

3. One-time requirements:
Generally, there are certain non-repetitive SDL requirements task per project. This category is called “one-time requirements”. These types of requirements are generally easy to meet. The period to complete each one-time requirement might range from one month to one year after the initiation of the project. 

Microsoft has developed a smooth process for the teams, in which they can react to the rapidly changing customer needs. While addressing the same, the team can come up with innovative techniques as well. This way, even if the teams are getting new requirements on time, they are making the product robust and more immune to threats that may arise due to the highly flexible nature of SDL-Agile processes. 

Looking to elevate your proficiency in project management and take your career to new heights? Our PRINCE2 Foundation training course offers comprehensive materials and expert instruction to help you achieve mastery with ease. Enroll now and unlock your potential!