Recently, Ryan O’Boyle and I hosted the webinar “Building Security Into the Agile SDLC: View From the Trenches”. We would like to take a minute to thank all those who attended the live broadcast for submitting questions. There were so many questions from our open discussion following the webinar that we wanted to take the time to follow up and answer them. So without further ado, the Q&A.
Ryan: Standardizing on one tool for tracking development work across all development teams, and using the same tool to track the security reviews gave both us and the development teams improved visibility.
Ryan: Just a team performing in a different way. This meant that while we had developed our core process around Scrum teams, we had to find a similar way to integrate with a new team operating with a different process.
Ryan: In our process, the Security Architect is responsible for working with the Product Owner to define security-related Acceptance Criteria or entire stories. As those participating in security grooming gain familiarity and certain patterns emerge, they can write them as well. I would recommend security training for everyone involved.
Chris: Yes, though I think you want to be careful of putting too many responsibilities on the Scrum Master. A Tech Lead can certainly be trained up to pitch in on some subset of the Security Engineer role, such as routine code reviews. This is similar to what we are rolling out with our Security Champions program, except that the Security Champion can be any member of the team. It will take longer for them to develop the expertise and intuition needed to perform tasks like security design reviews or focused penetration testing.
Chris: Modifying stories during sprints is a violation of Scrum principles, so if/when this does happen, we try to make sure it is addressed during Retro. Adding stories during sprints can still be challenging in the cases where the story was created on-the-fly. If it was pulled out of backlog, it would already have security criteria attached. However if it was a "just-in-time" story (e.g. acute customer pain point), we ask the Scrum Masters to inform us ASAP so that we can assess the security needs. In the near future it will be the Security Champion's job to keep an eye out for things like this.
Chris: We do not use formal threat modeling tools. At the story level, we are doing light, informal threat modeling focused heavily on protecting against unauthorized access to customer data. We plan to take some steps to formalize this, but we also want to be cautious of creating a bloated process.
Chris: We run automated static and dynamic analyses against each release candidate after code freeze. Every once in a while this picks up an implementation issue that might have been missed during code review, so it serves as a nice additional layer of defense. Additionally, we hire external consulting firms to perform a web app penetration test twice a year. All that being said, we'll absolutely miss things. Nothing is perfect. When we do become aware of any security issues that have escaped to production, we take a risk-based approach to determining the urgency of the fix. What's nice is that our deployment process allows us to test and push fixes relatively quickly if an off-cycle patch is needed.
Ryan: Yes, we consider security a part of our Definition of Done and to that point add and review against specific Acceptance Criteria on stories with security impact.
Ryan: Development teams run their own static analysis scans and do the initial review of the results. A security SME will review the results of later scan that incorporates many developers. Code review or pen. test findings that result from an in-sprint security review will be communicated back to the developer immediately so they can be addressed.
Ryan: Automation, automation, automation.
That is all we have time for at the moment, but check back next week for the second half of our Agile SDLC Q&A. In the meantime, if you found the Agile Security webinar useful, consider registering for CA Veracode’s director of platform engineering, Peter Chestna's webinar: "Secure Agile Through An Automated Toolchain: How CA Veracode R&D Does It". In this technical webinar, Peter will share how we’ve leveraged CA Veracode's cloud-based platform to integrate application security testing with our Agile development toolchain (Eclipse, Jenkins, JIRA) -- and why it's become essential to our success.