Taking the development world by storm since its introduction and popularization in 2001, the Agile Software Development model aims to keep development goals and timelines short and sweet, with frequent testing to deliver functionality as soon as it is available and ready. The Agile method promotes adaptive planning and encourages flexibility and rapid adaption to change.
While this helps organizations respond quickly to business pressures with incremental functionality improvements, it becomes a nightmare for security teams. I have been covering the securing the agile methodology for years, and despite the gains in productivity and business responsiveness, the security methodology continues to plague security professionals.
To further explain, Agile essentially promotes rapid iterations where code is released frequently. Often, new code is released once or twice a month, however in some instances, code is released multiple times per week, per day or even per hour. How do you begin to ensure new code and the newly introduced functionality is secure? The amount of code and potential side effects in a large application can be staggering, and developers are usually fully occupied pushing the code, achieving functionality goals, and meeting deadlines – security is often forgotten in the mix.
That said, would you publish a paper without spellchecking the text to save time? Likely not, and the same should hold true for software development. While there is no security spellcheck (but I’m sure it’s under development someplace), it is imperative that we change this approach to give some degree of security assurance for each release.
Obviously, with such a rapidly changing environment, we have to make sure that we do not employ point-in-time security controls. Security must be a constant, and as a result it needs to be integrated into the entire process. To do this, organizations must keep a few things in mind.
A Secure Framework
Organizations should ensure developers have security controls in place, or make sure they are using a highly secure framework. For example, out-of-the-box ASP.NET 4.5 has a higher number of security controls and default security settings than PHP 5.5. It is important to use the web application framework that works best for you and your organization, but security absolutely needs to be a part of that decision up front, as it gives developers a fighting chance. Additionally, training should be made available for developers to learn how to develop secure code on whichever framework they will be using.
Time for Security
The introduction of functionality in the Agile model takes place during a sprint. While Agile promotes rapid introduction of new code as it is ready, time should always be allocated to ensuring security in the sprint cycle. Too often I see this overlooked, and organizations need to make time allowances to ensure the code is secure.
Automation
While organizations can manually check code before it goes out, this is an extremely labor-intensive process and is often cost-prohibitive. Automation is key for most organizations as a result, and by automatically checking source code for security flaws, you can better ensure the security of that code before it goes into production. Either with staff on hand to look at the source code, or with an automated service, the goal is the same: putting out code that has had some minimal mode of verification or security assurance.
Sprint Bundling
If you are planning to add big ticket features in a sprint, make sure that security for those features is built into that same sprint. This should not be an afterthought. For example, if you are adding a web API so that users can consume data whenever they want, security needs to be built into that same sprint so that you are securing this new feature from the get-go.
No matter how you slice it, Agile Software Development introduces more risk into your environment. You are pushing code out faster as time goes on, and the goal is to make this rapid fire of code work to your benefit rather than your detriment when it comes to security.
This is absolutely possible if you keep these tips in mind. It is important to remember that your approach to security in the Agile model is not one-and-done. It is an ongoing, daily process. To make sure that no code goes out unassessed, planning, leveraging the right security controls, making time for security and leaning on automation should be key components of your security routine.
Source: http://blogs.computerworld.com/application-security/22315/secure-agile-software-development-never-one-and-done