How to Strike the Right DevSecOps Balance

In the age of DevSecOps, every developer is also supposed to be a security engineer – or, at least, developers are supposed to devote as much energy to security as to other aspects of app development.

DevSecOps is a great thing, and security should be among developers’ priorities. But, some days, I think the DevSecOps conversation needs to be tempered a bit. Security should be one goal for developers, but it should not be their only goal. Nor should security considerations force other priorities, like application performance and reliability, to take a back seat.

Here’s how to know if you’re taking security too seriously when you design and develop applications, and how to strike the right balance between security and other objectives.

Security, Developers and the Challenge of DevSecOps

Part of the reason why DevSecOps has become a trendy topic in recent years is that it upends the traditional relationship between developers and security.

In the traditional model, developers write code, then leave it up to security engineers to figure out how to make sure the code runs securely in production. Although developers in this model are expected to follow some basic best practices to mitigate security issues – like validating data input and trying to avoid buffer overflow vulnerabilities – they don’t typically go above and beyond when it comes to writing secure code. Nor do they participate much at all in the task of deploying applications securely or responding to threats and breaches that arise in production environments. That work in the traditional model is left to the IT department and security engineers.

DevSecOps aims to change this by involving developers more centrally in security operations. The driving idea behind DevSecOps is that, if developers better understand the security threats that their applications face in production, they can write more secure code from the get-go. They can also update their code more quickly to respond to threats that arise after applications have been deployed. And in general, they will assume greater ownership over security.

This all makes good sense. I’m not here to dismiss DevSecOps as an inherently bad idea, or suggest that we should return to the days when developers left it up to other people to deal with security issues.

DevSecOps Overkill

Nonetheless, I do think that there is such a thing as too much DevSecOps. If your team obsesses over security to the point that it undercuts other priorities, you have entered the territory of DevSecOps overkill.

You know you’ve reached that point when things like the following happen:

When you end up in situations like these, you’ve let security paralyze the rest of your development operations. These DevSecOps challenges leave you with an app that is very secure but not very usable in other respects. And that kind of defeats the purpose of creating an app in the first place.

Striking the Right Balance for DevSecOps

Conclusion

It can feel almost taboo to suggest that security alone should not constitute the be-all, end-all of development operations. Developers today are inundated with warnings about security risks. No programmer wants to be responsible for the next vulnerability that exposes millions of users’ data or triggers a major regulatory fine.

The best developers, however, are ones who learn to have security and eat it, too. In other words, they manage security threats effectively without allowing security considerations to paralyze other facets of their apps. DevSecOps is great for helping to do that, but only if you are careful to achieve the right balance between DevSecOps and other priorities, like release schedules and application performance.