At this stage the software delivered as part of the Sprint or Sprints is demonstrated, evaluated, and verified and is accepted or rejected by the business customer. This must include the examination of security. Just as the customer has business acceptance criteria, they should also create security acceptance criteria. While it seems to be black and white, it is not. Conditional acceptance is the norm. Often time the sponsor will only accept the Sprint delivery if this, that and the other thing is changed. As identified as conditions of acceptance, the rework is scheduled. Once scheduled, the rework required to meet the conditions for acceptance is done. Once the rework is done and tested, the rework is reviewed and demonstrated to the business customer to ensure the intent of the conditional acceptance has been met.
Capturing lessons learned is the process of gathering, documenting, and analyzing feedback that has been received during the Sprint. This is critical so subsequent Sprints can benefit from this experience. This is critical because capturing security lessons learned gives the team members a chance to reflect on tasks, events, and activities during the Sprint that contributed to security short-comings. In addition, capturing lessons learned requires a retrospective examination of the risk management implement and documenting successes and shortcomings.
Putting it all together, all the software developed to date must be integrated and validated together. Once this is done, it must be validated to ensure proper function. Monitoring and tracking are required in the short term to make sure all the software and systems components are working together properly and do not create security vulnerabilities. Interactions between systems must be tested from a security standpoint. New security test scenarios must be developed and executed within this step.
In addition, as discussed earlier, increased attention in terms of testing must be given to cross-site scripting, information leakage and SQL injection. Once everything is working together properly and is secure, it is ready to be released into production. Release Management (RM) is the relatively new part of all software development methodologies and projects. RM becomes the liaison between all the business units and IT to guarantee smooth transition to the new system. Finally, the time has come to move to the next Sprint. The wrap-up step results in the Sprint being officially closed. In addition, this step creates the project artifacts and ensures proper documentation and the backup and archive of the code. This step often requires changes to security monitoring processes and capabilities that are in place at the business.
The security industry has given 2008 the dubious distinct honor as the "data loss year" due to the significant number of sensitive information security breaches that occurred. In congressional testimony by Director of National Intelligence Dennis C. Blair, he stated that last year global companies may have lost over $1 trillion worth of intellectual property to data theft in 2008. Software vulnerabilities represent one of the leading causes. This should concern everyone involved in application development regardless of methodology. It should also be seen as a warning to Agile development projects that they need to ensure proper security is built in, not bolted on.