November 6, 2015
DevSecCon 2015 - Security in Continuous Delivery Becoming the New Normal?
Email sign up
I recently attended the first DevSecCon conference in London, organized by the London DevSecOps Meetup group, a rapidly-growing group of developers, operations staff, and security professionals. This non-profit conference was created for DevOps and SecOps practitioners to get together and share new ideas and best practices. It was a very full day of presentations, workshops, and open space events.
One of the things that struck me was that around 80% (my guess) of the attendees were developers. It's probably becoming less and less true to suggest that developers are only interested in cutting great code and getting it out to customers as quickly as possible. Professional developers take security considerations very seriously—after all, anything else could be career-limiting!
Also interesting was how enlightened security experts have moved from being traditional gatekeepers that like to say "no" to development partners that want to enable high speed and high scale security validation as part of rapid or continuous delivery. One quote that really stuck with me was from Scott Kennedy at Intuit: "Developers are like water; impossible to stop, they will always find their way around a block." We're seeing a similar trend across the security industry. It's a fool's errand to believe you can entirely block every potential attack; you do much better to work intelligently to limit risk, and then detect and react quickly when necessary.
I was, of course, happy to see the recommendation to have a version management tool at the heart of the DevSecOps pipeline. It is absolutely critical to have a single repository where all assets, from source code to deployed binaries, can be managed—and to always deploy from that repository. This "single source of truth" makes systems management, security, and audit trails both complete and easy to manage. The more systems involved in that pipeline (e.g. adding on additional tools for binary artifact management), the greater the complexity and potential for weak links in the chain. Most of those artifact tools were really built to overcome limitations in source code management tools that were designed for software source code and can't scale to handle real-life application deployment.
There were plenty of other best practices discussed including the need for "Compliance at Scale," "Security Policy as Code," and "Infrastructure as Code," the takeaway being that if it can't be expressed as code it can't be automated. This is also critical for being able to learn from version management and apply those lessons to security and infrastructure.
Another strong recommendation was to build a pipeline around tools that have full APIs. I was really surprised to hear that so many tools do not provide APIs or aren't easily scripted (for a list of the Perforce Helix APIs, take a look here).
Perhaps the best summary of the state of the union in DevSecOps was the comment by Stephen de Vries of Continuum Security: "Security testing is at the point quality testing was ten years ago in terms of integration into the development workflow."
Given the enthusiasm for the topic at the event (which is already looking to expand into the U.S.A. and France) and the rapidly changing landscape, I doubt it will take another ten years for DevSecOps to become the norm.