Home>Blog>3 Things Every SOC Team Needs to Know About DevSecOps in a Cloud-Native World

3 Things Every SOC Team Needs to Know About DevSecOps in a Cloud-Native World

5 Min read
Last Updated Thursday, October 14, 2021

Written by Dan Kaplan

Written by Dan Kaplan

It is one of the hottest buzzwords in the cybersecurity landscape not named zero trust. 

DevSecOps has grown in prominence as more organizations adopt a cloud-native approach to build and deploy applications faster, improve scalability and reliability, and emphasize continuous improvement.

The rising demand for the “Sec” part of the equation should not surprise anyone working in an industry that has long lamented when security is bolted on as an afterthought instead of built in. But with applications now cloud native and able to be, according to Oracle, “designed and built to exploit the scale, elasticity, resiliency, and flexibility the cloud provides,” the importance of proactive security once again must be highlighted within cloud-native developer circles.

With a new survey from Aqua Security reflecting a disproportionate level of awareness around what is required to protect cloud-native environments, including key components like containers, it may be high time for a refresher on the importance of embedding security into the development lifecycle. 

Watch the On-Demand Webinar: Evolving to a Cloud-Native SOC

It is worth reminding you that DevSecOps is a confusing moniker, as it technically contains three independent and distinct elements of an enterprise – development, security and operations – and does not merely tack on the familiar SecOps term.

Regardless, the security operations center (SOC) will play a big role in this blossoming synergy, especially with intuitive technologies like security orchestration, automation and response (SOAR) enabling SOC teams to seamlessly and speedily insert themselves into  coding processes and other engineering practices, essentially allowing the SOC to adopt traditional DevOps principles. 

First, a quick introduction to how DevSecOps got to where it is today, courtesy of Red Hat’s The Enterprisers Project:

DevSecOps extends the same basic principle to security: It shouldn’t be the sole responsibility of a group of analysts huddled in a security operations center (SOC) or a testing team that doesn’t get to touch the code until just before it gets deployed. That was the dominant model in the software delivery pipelines of old: Security was a final step, rather than something considered at every step. And that used to be at least passable, for the most part. As Red Hat’s DevSecOps primer notes, “That wasn’t as problematic when development cycles lasted months or even years, but those days are over. Those days are most definitely over. That final-stage model simply didn’t account for cloud, containers, Kubernetes, and a wealth of other modern technologies. And regardless of a particular organization’s technology stack or development processes, virtually every team is expected to ship faster and more frequently than in the past.

So what do security analysts and engineers need to know about DevSecOps?

  • Automation is king.

As a SOC professional, you should want insights into the tooling and development process for new software. So in the same way that the code of cloud-native applications is automated to easily allow engineers to deploy updates and ensure reliability, builds should also involve the automation of security assessments during the planning and production phases of the software lifecycle.

  • The “Sec” in DevSecOps should be cloud native. 

With networks, applications and other assets that the SOC protects increasingly being built on cloud-native foundations, it makes sense that the tools and platforms that security teams use – including the previously mentioned SOAR – are also constructed with this architecture. This will then traffic into the SOC the attractive benefits of cloud native: rapid innovation, scalability and business resiliency, all of which help improve threat detection, investigation and response.

  • DevSecOps supports a stronger security culture.

The fusion of development and security functions indicates a breakdown of silos is underway, and in a remote-centric era, that is a good thing for overall business chemistry because it means more collaboration is happening within disciplines that don’t typically speak the same language. Plus, anytime security can be viewed as a partner helps to disrupt the common perception within organizations that infosec is a highly risk-averse group that says “no” to any new tools, applications, cloud services or ways of doing things.

For more information on how SOAR can help support a successful DevSecOps program, visit siemplify.co.

Dan Kaplan is director of content at Siemplify.

Sign up for our newsletter and join thousands of your peers who receive monthly security operations tips and tricks.