Welcome to another round of Agile SDLC Q&A. Last week Ryan and I took some time to answer questions from our webinar, "Building Security Into the Agile SDLC: View from the Trenches"; in case you missed it, you can see Part I here. Now on to more of your questions!
Chris: It really depends on what the frequency is. If you're deploying once a day and you have automated security tools as a gating function, it's possible but probably only if you've baked those tools into the build process and minimized human interaction. If you're deploying more often than that, you're probably going to start thinking differently about security – taking it out of the critical path but somehow ensuring nothing gets overlooked. We've spoken with companies who deploy multiple times a day, and the common theme is that they build very robust monitoring and incident response capabilities, and they look for anomalies. The minute something looks suspect they can react and investigate quickly. And the nice thing is, if they need to hotfix, they can do it insanely fast. This is uncharted territory for us; we'll let you know when we get there.
Chris: You'd probably want to have that person work with one Scrum team (or a small handful) at a time. As they security groomed with each team, they would want to document as rigorously as possible the criteria that led to them attaching security tasks to a particular story. This will vary from one team to the next because every product has a different threat model. Once the security grooming criteria are documented, you should be able to hand off that part of the process to a team member, ideally a Security Champion type person who would own and take accountability for representing security needs. From time to time, the security SME might want to audit the sprint and make sure that nothing is slipping through the cracks, and if so, revise the guidelines accordingly.
Chris: Yes, the Security Satellite concept maps very well to the Security Champion role. BSIMM is a good framework for considering the different security activities important to an organization, but it's not particularly prescriptive in the context of Agile.
Chris: One way to approach this is to put a policy in place to determine whether or not the release can ship. For example, "all high and very high severity flaws must be fixed" makes the acceptance criteria very clear. If you think about security acceptance in the same way as feature acceptance, it makes a lot of sense. You wouldn't push out the release with a new feature only half-working, right? Another approach is to handle each vulnerability on a case-by-case basis. The challenge is, if there is not a strong security culture, the team may face pressure to push the release regardless of the severity.
Ryan: Our goal is to address any findings identified within the sprint. This means while it may not be next-day it will be very soon afterwards and prior to release. We have considered dedicated security sprints.
Ryan: Security grooming is a joint effort between the teams. In some cases the security representative, Security Architect in our terminology, attends the full team grooming meeting. In the cases where the full team grooming meeting would be too large of a time commitment for the Security Architect, they will hold a separate, shorter security grooming session soon afterwards instead.
Chris: Initially not very important, because we didn't have dedicated release engineering. The development and QA teams were in charge of deploying the release. Even with a release engineering team, though, most of the security work is done well before the final release is cut, so the nature of their work doesn't change much. Certainly it was helpful to understand the release process – when is feature freeze, code freeze, push night, etc. – and the various procedures surrounding a release, so that you as a security team can understand their perspective.
Chris: The first challenge is to measure all of it, particularly debt that accumulated prior to having a real SDLC! Even security debt that you're aware of may never get taken in to a sprint because some feature will always be deemed more important. So far the way we've been able to chip away at security debt is to advocate directly with product management and the technical leads. This isn't exactly ideal, but it beats not addressing it at all. If your organization ever pushes to reduce tech debt, it's a good opportunity to point out that security debt should be considered as part of tech debt.
This now concludes our Q&A. A big thank you to everyone who attended the webinar for making it such a huge success. If you have any more questions, we would love to hear from you in the comments section below. In addition, If you are interested in learning more about Agile Security, you might be interested in this upcoming webinar from CA Veracode's director of platform engineering. On April 17th, Peter Chestna will be hosting this webinar entitled "Secure Agile Through An Automated Toolchain: How CA Veracode R&D Does It". In this 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. Register now!