DevOps is on the rise. Back in 2018, MarketsandMarkets wrote that it expected the DevOps market to grow to $10.31 billion by 2023. That’s up from $2.90 billion in 2017, with a compound annual growth rate (CAGR) at 24.7% projected for the forecast period. Demand for DevOps solutions and services in response to the need for fast application delivery capabilities would likely help to drive this increase.
Even so, security issues are introducing some challenges for organizations. A study conducted by the Enterprise Strategy Group and commissioned by Synopsys Inc. found that 48% of respondents had knowingly pushed out vulnerable code into production due to time pressures. Patrick Carey, product marketing director for the Synopsys Software Integrity Group, noted that about half of those respondents had done so “because the vulnerabilities identified were discovered too late in the [development] cycle to resolve them in time.” Such weaknesses elevate the risk of a data breach, and they potentially carry reputational costs for organizations that don’t plug those gaps before they release their products into production.
These findings beg the question: Why are organizations struggling with their security efforts for DevOps? What’s not working for them?
This blog post will explore these questions in terms of a cultural divide that exists between DevOps and security teams. After exploring where each team is coming from, this blog post will provide recommendations on how organizations can work to foster cooperation between their security personnel and DevOps teams.
The Great Divide: Understanding the Issue
The cultural divide alluded to above boils down to a false understanding of security and its impact on the development process. DevOps personnel are required to work within short development cycles to meet their employers’ evolving business needs. Subsequently, some organizations might interpret security as an opponent to their developers’ speed and respond by sacrificing security for the sake of speed. This decision enables misconfigurations, vulnerabilities and other security weaknesses to make their way into production.
However, this interpretation overlooks an important reality: Many DevOps teams view security as a nuisance that gets in their way and slows down their work. Retroactive fixes ultimately take time and effort. In response, organizations might hold back on investing in the security of their DevOps processes, thus creating “technical debt” in the event that the work doesn’t get done.
With that said, organizations have an incentive to rethink how they conceptualize security so that they can avoid these costs and keep their development processes running smoothly. But this raises an important question: How can organizations go about doing that?
How to Balance DevOps and Security
First, organizations should work to foster a culture of communication through which security personnel and DevOps team members can learn from one another. One solution to start with is having leaders from both teams “walking in the other team leader’s shoes,” thereby allowing them to share information and discuss their perspectives.
Such communication will be effective only if personnel understand where the other side is coming from, however. That’s why organizations have an obligation to make their security policies and development workflows as understandable and implementable as possible. With this transparency, security and DevOps can begin to craft a way forward.
Organizations can help out by encouraging both security teams and DevOps personnel to expand their knowledge. With respect to the former, security personnel have an interest in learning how to frame their message in the right language. It’s important to acknowledge that security teams can speak of potential security issues burdening projects with unexpected work and/or threatening operations’ availability with longer mean response times.
Of course, security teams need to have a basic understanding of where developers and operations personnel are coming from. They can do this if organizations support them in learning about programming languages and how applications are developed. Subsequently, security personnel can use this knowledge to hold more credible discussions with their Devs and Ops counterparts as well as to properly configure their organizations’ Kubernetes.
StackRox emphasizes the importance of administrators using automation to review their environments for possible misconfigurations:
That’s because in a sprawling Kubernetes environment with several clusters spanning tens, hundreds, or even thousands of nodes, created by hundreds of different developers, manually checking the configurations is not feasible. And like all humans, developers can make mistakes – especially given that Kubernetes configuration options are complicated, security features are not enabled by default, and most of the community is learning how to effectively use components including Pod Security Policies and Security Context, Network Policies, RBAC, the API server, kubelet, and other Kubernetes controls.
As far as DevOps personnel are concerned, training is key. Organizations should specifically consider training their DevOps teams in secure coding practices and educating their employees about attackers’ tactics. These individuals can then incorporate that knowledge into their coding practices and development processes. Additionally, organizations can uphold this security mindset among DevOps personnel by assigning security responsibilities to an individual on the DevOps team or to someone in a new position. They can then overlook security protocols among the DevOps personnel.
Positive Focus Goes a Long Way
The key to making security and DevOps teams work together is not taking their collaboration for granted. Like any relationship, organizations need to foster this cooperation by using positive focus and work to bring these two groups together. In that way, they can enjoy both the speed of DevOps as well as the security to stay safe against evolving digital threats.
