The DevOps Revolution Won't Be Complete Until Security Is Included
April 29, 2021

Hillel Solow
Check Point

The DevOps revolution of the past decade has been driven by an increasingly fast-moving world. Where once the release of new software and applications was an event that happened every few months, it's now a constant, ongoing process with new code rolled out continually. DevOps teams have embraced this challenge by breaking free of the traditional siloed approach, and owning more of the development cycle themselves, including quality testing, integration and deployment. However, there's a major component that DevOps is still failing to take responsibility for: security.

Previously in app development, developers' main role was to write code that performed a specific function, regardless of the quality of the end product — that was the QA team's responsibility, not theirs. The DevOps model arose out of a recognition that this way of working simply wasn't tenable anymore. Empowered by advances in cloud delivery, containerization and microservices, applications can now be created and deployed by the same team, without the need for constant hand-offs to other departments. This means that DevOps is now responsible for the quality of the end product — in terms of user experience, speed, resilience, etc — rather than just its functionality.

However, attitudes towards security are still stuck in the old way of thinking. While DevOps has taken on responsibilities that used to reside with other teams in order to make the non-stop cycle of software releases more efficient, there still seems to be a general belief that the security team remains responsible for protecting DevOps' products. There may be cultural and organizational reasons for this belief linked to the perceived power and centrality of the security team in many companies. But the fact remains that the DevOps revolution won't be complete until the security of products is also baked into the software development process.

In many ways, this is a no-brainer of a statement. If DevOps now owns product quality — in other words, making sure that application performance is optimal — then surely a big component of that is verifying upfront that code doesn't contain known bugs or backdoors which could impact its security. If you built a car that was perfect in every way except it had a tendency to catch fire at high speeds, you would quickly conclude that there was a major problem with the quality of its design. The same is true for a website that is easily hacked because not enough was done to protect its code. If your customers' bank details have been stolen, you can be sure you've got a quality problem.

Perhaps due to the overarching presence of the security team within the modern company's IT organization, right up to board level if a CSO has been appointed, DevOps may have been content in the past to sit back and let these guys "do their job." But with security being a major part of the product quality equation, this is no longer a sensible mindset to adopt. If the website or application you've launched gets hacked or becomes infected, DevOps will increasingly be held responsible for this failure rather than the security team. To say that DevOps shouldn't have to worry about how secure their code is because another team will catch that problem is analogous to disregarding the expense of a project just because there's a finance department.

Yet this isn't just about facing up to responsibilities. Rather than seeing the security aspect of software development as yet another burden on their shoulders, this is an opportunity for DevOps to further extend its authority and influence. Instead of waiting for tools and processes to be mandated by the security team, DevOps teams need to be more proactive in finding and selecting the solutions they need to write, configure and deploy secure code the first time. After all, DevOps are more likely to understand which would be the most useful tools to have in those initial code creation stages, and which would strengthen their ability to work in an agile fashion.

It's clear that in the past there have been issues with how the security function has been presented to developers and the wider company. There was a time when risks and threats to the enterprise and its online presence seemed to multiply exponentially, and companies were forced to respond by deploying ever more complex remedial products, such that IT security became its own discipline and an industry in itself. In this new and rather daunting world, there was often a sense among other IT stakeholders such as developers that security was too far outside of both their understanding and their remit.

However, we need to move on from those days. With the prevailing mantra that prevention is always better than remediation, and that security needs to adopt more "shift-left" practices to be truly effective, DevOps might be surprised to discover how receptive their security team is to sharing responsibility and working more collaboratively. While the security team may still oversee and have input into relevant parts of the DevOps process, they should no longer have to contend with code that hasn't been written with security in mind.

DevOps must regard security as a core facet of software quality and performance. There's definitive evidence of movement in this direction, particularly with the recent emergence of the so-called DevSecOp culture. Yet really, this is a misnomer, because "Sec" shouldn't have to be a separate element that's pulled out and highlighted within the DevOps process — rather, it should be totally integral to everything that DevOps does. But until that's the case, the DevOps revolution will remain incomplete.

Hillel Solow is a Cloud Security Strategist with Check Point
Share this

Industry News

May 22, 2024

Mendix announced a partnership with Snowflake to enable the enterprise to activate and drive maximum value from their data through low-code application development.

May 22, 2024

LaunchDarkly set the stage for “shipping at the speed of now” with the unveiling of new features, empowering engineering teams to streamline releases and accelerate the pace of innovation.

May 22, 2024

Tigera launched new features for Calico Enterprise and Calico Cloud, extending the products' Runtime Threat Defense capabilities.

May 22, 2024

Cirata announced the latest version of Cirata Gerrit MultiSite®.

May 21, 2024

Puppet by Perforce announced a significant enhancement to the capabilities of its commercial offering with the addition of new security, compliance, and continuous integration/continuous delivery (CI/CD) capabilities.

May 21, 2024

Red Hat and Nutanix announced an expanded collaboration to use Red Hat Enterprise Linux as an element of Nutanix Cloud Platform.

May 21, 2024

Nutanix announced Nutanix Kubernetes® Platform (NKP) to simplify management of container-based modern applications using Kubernetes.

May 21, 2024

Octopus Deploy announced their GitHub Copilot Extension that increases efficiency and helps developers stay in the flow.

May 20, 2024

Pegasystems introduced Pega GenAI™ Coach, a generative AI-powered mentor for Pega solutions that proactively advises users to help them achieve optimal outcomes.

May 20, 2024

SmartBear introduces SmartBear HaloAI, trusted AI-driven technology deploying across its entire product portfolio.

May 16, 2024

Pegasystems announced the general availability of Pega Infinity ’24.1™.

May 16, 2024

Mend.io and Sysdig unveiled a joint solution to help developers, DevOps, and security teams accelerate secure software delivery from development to deployment.

May 16, 2024

GitLab announced new innovations in GitLab 17 to streamline how organizations build, test, secure, and deploy software.

May 16, 2024

Kobiton announced the beta release of mobile test management, a new feature within its test automation platform.

May 15, 2024

Gearset announced its new CI/CD solution, Long Term Projects in Pipelines.