On Monday, I attended portions of the DevOps seminar at the RSA Conference. Today (Tuesday), the conference featured another DevOps-related session, but this time, it was a panel “throw down,” which turned out to be a bit more (to use the moderator’s words) controversial and lively.
Shannon Lietz of Intuit moderated the discussion between Chris Wysopal, co-founder and CTO of Veracode; Caleb Sima, co-founder and executive chairman of Bluebox Security; and Gary McGraw, CTO of Citigal. The three panelists had a lot to say about how DevOps impacts security, and the general state of the security/DevOps relationship. The key point I took away from this discussion is that development and DevOps are frustrated.
They are frustrated with the security processes and tools that are thrust at them. They are frustrated with the lack of communication between development and security, and they are frustrated with the way security tends to interfere with their teams’ goals.
This frustration is at the heart of Veracode’s “Make Code not War” campaign at RSA. Developers, DevOps and security need to stop acting like they are on separate teams, and realize they actually have a shared goal: to produce high-quality software their users can trust.
But if security keeps talking at DevOps, and DevOps keeps looking at security as an impediment slowing them down, the dream of secure and high-quality software will never be realized. As our own Jeff Cratty recently pointed out, development feels let down by security teams. Often, security teams look solely at the problem of security, and not at the problem from the developer’s perspective. I heard echoes of this in Shannon’s questions during the panel discussion. She asked questions about tests running too slow to fit into the development cycle, made statements about tools having not caught up to the needs of developers, and stated that development doesn’t have time for security.
The panelists did offer some ideas on how these perceptions could be combated. To start, I believe it was Gary who said security should be part of the design phase, but we never see that in reality. The panelists also discussed how they can better work with developers and help them be more successful. The answer to this dilemma, like so many others in society, came down to education. Interestingly, not one panelist suggested offering developers security training. Instead, they all felt it was better to give developers goals (example: eliminate SQLi vulnerabilities) and then help them understand why the goal is important and how they can accomplish it.
It is clear some security professionals view DevOps as another challenge to overcome – a nuisance that just makes their job harder. If there is one thing I took from both DevOps presentations this week, it is that DevOps and security do not have to be adversaries. If both teams can try to understand each other better, we will have more secure software, without slowing down innovation.