Application security has become a critical component of all software development efforts. It includes all measures taken throughout the software development lifecycle to prevent programming flaws from being exploited. The flaws that creep in during the requirements, design, development, deployment, upgrades, or maintenance stages of applications become the basis of cyber attacks.
Lack of security built into applications coupled with poor programming techniques are routinely exploited by hackers and has helped contribute to massive monetary losses attributed to data breaches and theft of intellectual property. That is why security must be an integral part of the application development methodology and the Agile process is no exception.
The Agile process is said to have been born back in November 2001. This approach to software development has been gaining ground in recent years. The Agile process is focused on iterative discovery and development that aligns development with customer needs and company goals. That said, I have found that the basic characteristics of Agile tend to push security off till after the business functionality has been built. I have found that many times security is not included in the initial release of functionality, thus making Agile security bolted on rather than built in.
In the examination of application security issues, I tend to group them into two categories -- business logic flaws and technical vulnerabilities. It has been recognized that security must be built into applications rather than bolted on at the end. This presents a challenge when using the Agile methodology. It also has caused great debate about the suitability of Agile for applications that involve sensitive security information or applications that could provide a covert pathway (aka backdoor) into other systems.
I like many believe the Agile processes are unsuitable for security-sensitive software applications. This is primarily due to the lightweight, informal, build-as-you-go nature of Agile processes. Security must be built in, not bolted on; therefore, it must be integrated throughout the Agile process.
Security starts before the project. The security strategy and objectives must be established at the very beginning. After that and during the project definition step, high-level security requirements and objectives must be established, documented and communicated to the development team. Once we have these cornerstones of security set, we must assess what is necessary to meet these objectives. In the scoping and estimation step, time must be allocated to review the evolving requirements and refine the security requirements and objectives. After the scope of security is defined and the level of effort estimated, high-level security plans are developed. When you are developing these high-level security plans, you must establish security coordination activities that evaluate the security measures at each point along the iterative development effort and make sure those measures are considered. Now the foundation has been established and we can move on to security within the Sprints.