3 Key Security Concepts From The State of DevOps Report 2016

Recently, the long awaited 5th edition of the 2016 state of DevOps report was released by Puppet

More than 4,600 technical professionals completed the survey this year and the report offers a close-up view of deployments, security, stability and employee loyalty at organizations that have adopted DevOps practices. In previous years security appeared not to be in focus, however in this years report, there is an obvious paradigm shift where security it squarely in focus and highlighted as a priority.

The remainder of this blog post explores the 3 key security concepts as quoted in the report.

1. Security is everyone's responsibility

"The more we work with organizations as they progress through their DevOps journeys, the more we hear the same theme: Quality and security are everyone’s responsibility."

Contrary to common belief security is not the responsibility of one group in isolation. Applications are not given to that team to be "secured" before they are being deployed. Yes, there is a need for a central group to provide the required level of governance and ideally serves as a center of excellence. They become enablers of the development teams and help them succeed with building a secure application in the most efficient and frictionless way possible. Security is not their sole responsibility, however. This is also in line with point 9 of Deming's "Fourteen Points for the Transformation of Management" which states "Break down barriers between departments. People in research, design, sales and production must work as a team, to foresee problems of production and in use, that may be encountered with the product or service." Security is just another facet of that. Ultimately the business has to achieve its goal and everyone has to be working together to make that happen.

2. Build Security In

"[...] by building quality and security into the software development cycle, high performers spend less time [...] remediating security issues, and spend more time on new, value-adding work."

This concept also stems from Deming's "Fourteen Points for the Transformation of Management" and is stated as "Cease dependence on inspection to achieve quality. Eliminate the need for inspection on a mass basis by building quality into the product in the first place." 

Many organizations are still leaving application security to chance by putting their trust solely on Penetration Testing after development on a release is complete. This has been the practice for over a decade now and the drawbacks are well understood. Late identification of issues is costing businesses valuable time and resources that could be spent on more important things. 

Building security in is about building quality and security into development lifecycle from the very beginning and throughout all subsequent phases. This way not only a large portion of vulnerabilities are prevented, but multiple feedback loops along the way ensure that vulnerabilities are identified early. Early identification dramatically reduces the cost, time, and effort required to fix a vulnerability. Security should already be considered during requirements gathering and backlog grooming sessions to provide the biggest benefits.

3. Automate

"Ideally, all this work will be automated and put into our deployment pipeline. By automating these activities, we can generate evidence on demand to demonstrate that our controls are operating effectively, whether to auditors, assessors, or anyone else working in our value stream."

Automation is always the way to go. This is further amplified by the lack of information security professional on a global level. In order to efficiently be able to scale and provide security feedback continuously and across the entire application portfolio, security work has to be automated as much as possible. However, it is important to understand what can be automated and what can't. Automation won't replace skilled and experienced experts, but can help make their work more meaningful and challenging by eliminating most of the mundane tasks.


The State of the DevOps report concludes that the integration of security objectives is just as important as the integration of other business objectives. This is illustrated in the graphic below.

Source: 2016 state of DevOps

By making security everyone's responsibility, building security in and automating it, high performers spend 50 percent less time remediating security issues and can spend more time on new work, such as building new features.

Quotes, content excerpts, and images in this blog post have been taken from the 2016 state of DevOps report.