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

July 26, 2021

Parallel Agile announced a new version of CodeBot, a low-code MERN stack application generator.

July 26, 2021

Appian unveiled its new Appian Japan regional office.

July 26, 2021

CloudTruth raised $5.25 million in seed funding led by Glasswing Ventures and Gutbrain Ventures, with additional funding from Stage 1 Ventures and York IE.

July 22, 2021

Postman successfully obtained the System and Organization Controls (SOC) 2 Type 2 and SOC 3 Type 2 reports for the Postman API platform, meeting critical industry standards relative to the Trust Services Criteria for security, availability, and confidentiality.

July 21, 2021

Scrum.org announced its new Professional Agile Leadership – Evidence-Based Management (PAL-EBM) training course.

July 21, 2021

BMC announced several new innovations and integrations within the BMC Automated Mainframe Intelligence (BMC AMI) and BMC Compuware portfolios designed to improve threat detection and response and expand access to mainstream DevOps tools to modernize mainframe applications and increase developer productivity.

July 21, 2021

CognitiveScale announced the release of Cortex Fabric Version 6—a new, low code developer platform for automation, augmentation and transformation of knowledge work and digital experiences.

July 20, 2021

JFrog announced the closing of the previously reported acquisition of product security company Vdoo.

July 20, 2021

Wind River has introduced its latest release of Wind River Studio.

July 20, 2021

Sysdig announced intent to acquire Apolicy.

July 19, 2021

Red Hat announced Red Hat Advanced Cluster Management for Kubernetes 2.3, the latest version of the company’s enterprise-grade Kubernetes management offering.

July 15, 2021

Platform9 announced the launch of Platform9 Managed KubeVirt.

July 15, 2021

ShiftLeft announced general availability of ShiftLeft Educate, a solution that delivers highly-effective security training for developers within the developer workflow.

July 15, 2021

Appfire announced the acquisition of Spartez Software.

July 14, 2021

Contrast Security announced its integration with Secure Code Warrior to deliver security contextual micro-learning modules to enhance developers' skills to easily fix vulnerabilities without the need of a security team.