To keep up with the demands of working in the cloud – and do so securely – we need to incorporate security practices into the application development and deployment pipelines. The term “DevSecOps” describes this process. Unfortunately, the transformation to DevSecOps can lead to friction between Security and DevOps teams. The good news is that it doesn’t have to be this way. Enterprises can adopt practices that reduce conflict and help make the journey to DevSecOps successful. Purpose-built security tools can also empower DevOps teams to make this transition.
Importantly, the information and conclusions presented here are based on conversations I have had with DevOps, Security and DevSecOps leaders from the finance, retail and media industries. Those experiences have given me insight into the concerns these teams tend to have, as well as information and ideas about how they can be addressed.
Emergence of DevSecOps
Innovative products and services catering to end-user needs and preferences require applications to be deployed with great agility, frequency and scale. Consequently, development teams leverage cloud and container platforms in conjunction with a DevOps practice to meet business objectives.
Security teams, tasked with protecting customer data and apps, have a hard task under normal circumstances. The adoption of highly elastic and scalable infrastructure – frequently deploying resources from hundreds to a thousand times a day – puts a tremendous burden on security teams that are ultimately unable to meet these requirements.
DevSecOps, when done right, has the ability to inject security in a cloud native manner to provide vulnerability management, help with compliance, and offer misconfiguration and runtime protections. However, security and DevOps teams have often been at odds with each other in their efforts to achieve their respective objectives.
Both DevOps and Security teams can obtain a better understanding of the reasons that contribute to prior failed attempts at DevSecOps. Implementing certain steps can also enable a successful transition.
Marching Toward Different Goals
The term “culture” is often used to describe people, process and tools that enable organizations to accomplish business objectives. However, it has been hard for many organizations to embrace and acknowledge the cultural barrier that exists between security and DevOps teams. It is important to understand these differences before discussing their consequences. Some major differences are:
DevOps Culture |
Security Culture |
| Security inhibits innovation and agility. | Does not trust DevOps to get security right. |
| Security is hard to adopt. | Needs to ensure compliance and protection. |
| Security is not a DevOps function. | Do as I say in order to sanction your application. |
This mismatch precipitates undesirable outcomes for the enterprise as a whole:
- Apps with critical vulnerabilities are deployed into production.
- No visibility into the compliance posture (apps, cloud and container platform).
- Applications fully exposed to the internet.
- No record of highly ephemeral workloads.
- Inability to correlate app behavior – sanctioned or unsanctioned.
Toward a Common Goal
There is no silver bullet or switch that can be flipped to adopt a DevSecOps practice. The transformation to DevSecOps is a process of continuous improvement, not an end in itself. Improved communication, collaboration and, most importantly, empowerment can help bridge the cultural divide.
Communication | Process
Good communication helps to put in place a process that enables security teams to clearly articulate the desired outcomes, such as full visibility into vulnerabilities, compliance failures and misconfigurations prior to applications being deployed into production. Conversely, it will help DevOps teams to recognize that it's far “cheaper” (in terms of breach and reputation) and efficient to address these issues in the CI/CD pipeline as opposed to on a running production environment. Establishing consensus and enabling a continuous process of improvement dramatically reduces the attack surface.
Collaboration | People
Better collaboration among people allows both teams to partner to converge on a strategy to minimize the attack surface. For example, security teams desire that cloud misconfigurations and critical vulnerabilities be detected and addressed when a pull request (PR) is made. DevOps teams are willing to sign up for this requirement, as it is much easier to address these issues while a feature is being developed, aided by instant feedback (with data provided as a pre-check failure in the PR), as opposed to being bolted on after deployment (far more complex to accomplish).
Empowerment | Tools
Empowerment through tools ensures that security teams provide DevOps teams with the right tools to take ownership for the security posture of their applications. Providing security tools for DevOps dramatically increases the willingness and ability of DevOps teams to inject security into their pipelines. For example, security needs to provide tools to:
- Scan infrastructure misconfigurations when a PR is made.
- Scan container images when the image is built or after it is checked into a registry.
- Decentralize security, by enabling DevOps teams to specify, consume and tweak security policies for their respective teams and pipelines.
Taking these steps is a recipe for success in the transformation to DevSecOps, wherein:
- Security teams trust DevOps teams to take ownership for security.
- Security empowers DevOps with the right tools to adopt DevSecOps.
- Culture change happens organically.
- Security partners with DevOps to adopt DevSecOps.
- Security adopts a trust, but verify posture.
- A process of continuous improvement strengthens the security posture.
To learn more about bridging the divide between security and DevOps teams, you can watch our Cloud Native Live virtual summit on-demand.