The Agile Movement
In my previous blog, Developing a Strong Application Security Program: Part 1, I looked at aspects of a successful application security program as it pertains to a more traditional waterfall Software Development Life Cycle (SDLC). In part two of this series, I’ll focus more on an agile-based SDLC and options for implementing a successful application security program.
Let’s briefly describe some of the differences between a traditional waterfall SDLC and agile SDLC. In a waterfall SDLC, there are clear project objectives through each phase of development. Typically, each project consists of several phases: planning, design, coding, and finally testing. Security teams are injected into the phases and should have sign-off authority on each phase before the project continues to the next. I detailed security’s role in this type of SDLC in the first part of this series.
Agile, on the other hand, includes all of these phases in iterations over time. One iteration will include some planning, some design, some coding, and finally some testing. The next iteration will include the same, until the entire application is built and ready for release. Each iteration will aim to develop a new piece of functionality within the application, or to fix bugs identified in testing of the previous iteration. The goal of an agile SDLC is to keep teams involved in face-to-face interaction, keep the scope flexible, and to overcome some of the drawbacks of the more traditional waterfall SDLC. I would describe it as taking the traditional phases of the waterfall SDLC and packing them into smaller chunks for each iteration within an agile SDLC. It is important to note that I am using the word ”iteration.” ”Sprint” is also an acceptable term for describing an iteration. I may use them interchangeably during this blog.
Before I get to some options for developing a successful application security program, I would like to address some challenges that can arise when introducing security within an agile SDLC.
- The resource requirements for the application security team can get quite complex if not managed appropriately, especially in larger organizations with many custom applications.
- Both the scrum master/agile master and the developers need to understand secure programming, to facilitate this in an agile based environment.
- Changes to the scope during any iteration can introduce additional risk that will have to be identified and managed carefully.
- Security’s role may not be required during each interaction. This is especially true when there aren’t any changes to a component between iterations.
With the above challenges in mind, I will attempt to identify a few options for implementing an application security program within an agile environment. Each option will focus on balancing the resource requirements with the business requirements for using an agile SDLC, while at the same time attempting to maintain a level of quality in the application security program with the ultimate goal of reducing risk in the SDLC.
Option one takes the recommendations from part one of this blog and squeezes it down into the agile SDLC. The security team is engaged throughout each component providing input against organizational standards and policies to make sure each component is in compliance with the organization’s security practice. The main difference is that both static analysis and dynamic analysis are performed after any testing and before any analysis. This helps the next iteration focus not only on fixing bugs found during the coding component, but also addressing any security vulnerabilities in the previous iteration’s code. The next iteration will follow suit.
This option, while incredibly thorough, may offer opportunities for more efficiency. For example, if designs do not change between several iterations, there really is no need to re-review the same design specifications. Or, automation for some of the security testing/review steps may provide additional efficiency benefits.
A sample step-by-step agile iteration may look something like this:
- Security teams validate that the design meets current organizational security standards.
- Security teams have little input here, however, developers/scrum master/agile master needs to know secure coding techniques.
- Security teams perform static code assessment after all other non-security tests are finished.
- Security teams perform dynamic assessment.
- Security teams present findings from testing and offers remediation guidance for next iteration.
Remember the challenge with resource requirements I mentioned earlier in this blog? Imagine an organization with 100 applications continually going through this process. Depending how long each component takes, you could completely tie up one application security engineer with only a few projects – and for both large and small organizations, it can be very difficult to devote these kinds of security resources to projects.
In line with option one, a similar process is followed with the following caveats:
- Security teams are engaged only for any changes to previously approved design elements or on new design elements only.
- Scrum master/agile master runs code through automated static code assessment tool.
- Static analysis moved to code component.
- Dynamic analysis only on new code, or to validate remediation of vulnerabilities identified in previous iteration.
- Scrum master/agile master presents automated static code assessment tool findings. Security teams offer remediation guidance.
- Security teams present dynamic assessment findings and offers remediation guidance for next iteration.
In line with option two, there are even more efficiencies introduced.
- No change from option two.
- Static code analysis performed every two or three iterations instead of every iteration on new or changed code.
- Dynamic analysis performed every two or three iterations instead of every iteration.
- Analysis Component
- No change from option.
If I were in charge of developing an application security program within an agile environment, option three would be the option I would try first. This option offers a lot of benefits in resource requirements and makes the most sense from a business perspective, without sacrificing thoroughness. Security teams are still engaged from the earliest component on up to the end. Security teams are then used as efficiently and effectively as possible to provide input and analysis after a few iterations have transpired. This still allows security teams to discover vulnerabilities early on and provides an avenue to fix them before final release.
But where does penetration testing come in? I fully believe penetration testing is necessary for risk identification, and it can be extremely useful for an agile SDLC. I would save penetration testing until just prior to release, as a final check. This is due to the considerable resources penetration testing takes as a result of manual and automated testing. Integrating penetration testing into the life cycle of each iteration doesn’t make sense and would waste resources. A penetration test succeeds when the whole picture comes into view, not when a small piece is implemented into the picture. Because security is integrated into each component of an iteration, we can avoid wasting resources and confidently perform a single penetration assessment prior to release. This will catch anything that may have been missed during the product’s development and testing period. Remediation and at least one retest should follow provided any vulnerabilities were identified that may introduce a level of risk beyond what the organization can absorb. Some sort of exception process will handle any security issue that can’t be remediated either during any iteration or just prior to release. Each organization should have its own policy around that kind of exception handling.