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:
- You repeatedly fail to keep up with your target release schedules due to security delays.
- You forego performance or feature enhancements in your app because you worry about the security risks they could introduce.
- Your development roadmap is structured around security alone, without regard for other types of updates.
- Your app suffers from performance or reliability issues because you’ve decided to prioritize security instead.
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
- How can you find that healthy balance between security and other priorities? There’s no simple trick, but the following strategies may help, especially for teams that have embraced the DevSecOps concept:
- Approach DevSecOps as an equal partnership between developers and security engineers. Don’t treat it as something that security engineers have to lead. Security engineers have as much to learn from developers as developers have to learn from security engineers.
- Along similar lines, assume your developers already have security expertise. DevSecOps might help them learn more, but you don’t want them to feel like you believe they are totally helpless and unable to write a single line of secure code without guidance from security experts. If DevSecOps feels remedial to developers, you’ll hinder their ability to design and write quality apps.
- Test your app on real users. It’s great to perform security tests and automated performance tests, but you should also be evaluating how actual users respond to the features you’ve included. This will help you identify areas where security undercuts other aspects of the user experience.
- Realize there will always be security flaws. Perfectionism is a recipe for paralysis when it comes to any aspect of coding. No matter how hard you try to avoid security vulnerabilities, you’re still going to have them. Accepting this fact will help you to keep moving forward even if your security posture is not flawless.
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.
