What is DevSecOps, and What It Isn’t

It’s enjoyable to watch the technology industry deal with new terminology. As a former Gartner analyst, the vendors want to craft the narrative to suit their marketing needs. This happens across all industries in IT, where complexity and change are paramount. Movements that are created by the community and adopted organically are always the best examples of how things should happen and how practices are actually built. 

A perfect example of this is how the DevOps movement arose. It was conceived by a group of practitioners in 2008. In the next decade, DevOps exploded and is now the norm as to how modern organizations build and operate software. To reduce engineering toil and increase efficiency, there must be a substantial investment in automation as code. This has been taken to the extreme in the last 15 years with continuous release pipelines. 

We can ensure that all software released is passing through gates of automation, ensuring management is as efficient as possible. Unfortunately, this doesn’t cover everything today, but we are getting there as an industry.

How Security Factors In the DevOps Process

Security is a challenge for all organizations, there are always too few security experts and a much larger team building and operating software. There will never be enough security expertise to protect the organization. Security is a team sport; there must be extensive education, enablement, and facilitation to ensure all teams own security. 

The next silo which organizations would like to fix is the one between operational and development roles with security. This trend is better known as DevSecOps and one which vendors have been talking about for several years. The reality is that this is not so much about the teams merging (however that does need to happen) but instead injecting security into the DevOps processes in a more streamlined manner. Realistically, the budgets and teams across security and DevOps will probably not merge for another decade, or possibly never. That doesn’t mean that DevOps teams will not be buying security tools; we already see that happening regularly for the release pipeline today. 

Why DevOps and SecOps Teams Can (and Should) Merge

In the target customers for Logz.io, we have seen more merged teams where DevOps and Security eventually roll into the CTO. This means they’re choosing to implement unified tools in observability and security, versus having different vendors. This optimizes the data collection to reduce redundant data being collected. Similarly, vendors are merging between internal IT and production systems to build efficiencies across security and operations. 

The ultimate outcome is that SIEM costs or Observability costs can be reduced by 30%-40%. Naturally, each vendor charges differently, so it could, in fact, be much higher savings. The advantage of having these consolidated is that when detecting security or operational incidents as they are passed between the security team and the application owners in DevOps, the data can be shared. One view across teams has a lot of value in speeding up investigation and resolution of security incidents. 

We will keep a close eye on these trends to ensure both our DevOps and Security product offerings have the most value across both teams as the DevSecOps trend continues. Look for more visibility across Kubernetes and pipelines in the future from Logz.io.