Cutting corners in DevOpsSec – Are your applications really Secured?

I’ve been planning to write this article for a while now. The application security industry, the one I’ve been part of for over a decade is changing its course and I’m fearful of its new path.

I’ll start by saying that I love DevOps. Thanks to DevOps and continuous delivery, my customers can enjoy newly delivered features every other week, and more often if needed. Issues get fixed quickly, we can try out new experiences with selective customers and rapidly correct course when required. I also admit that I am no expert on it, my knowledge of it came mostly from reading “The Phoenix Project,” talking to others and my own experience as a product manager working with a DevOps team. I myself had never developed in a DevOps team before moving to the product management side.

The birth of DevSecOps

DevOps was born from the realization that the teams involved in the creation of a product can’t work in silos. Producing a high quality, stable, and reliable product is a joint responsibility. It relies on dev, QA, and operations teams that must work together to reach those goals. Unfortunately, as many have noted, security was a late comer to the DevOps model. Security was an afterthought. Having a secured product was considered the responsibility of the security team. It took a few years and that approach has started to change. The software industry realized that as with quality, having a secured application is a cross-team effort and DevSecOps was born. But, to get developers engaged something had to change. So, with noble intentions, security practitioners took a good look at some of their declared archaic experiences and practices. An honest attempt was made to update and become better fit to modern-day development paradigms.

It’s this writer’s humble opinion that it has all gone too far.

Lower security standards or Level set developers expectations

I attended the OWASP AppSecUS conference two weeks ago. Great conference. Excellent sessions and a lot of good discussions with other community members. It was refreshing to hear the same mantra repeated over and over: developers are our customers; we need to fit into the development workflows and expectations. It felt that there exists an agreement on the new role of the security practitioner in today’s world. Instead of a strict cop that tries to scare everyone, a guide that helps developers produce secured products. But, following those I also heard that leading scanning tools can’t complete a thorough analysis in a very short amount of time. And so, it now has become perfectly acceptable to lower security standards, rely solely on quick and shallow scans, even though those will miss vulnerabilities. I’ve been told that in these DevOps days, if we won’t play nicely with the developers, they won’t play with us at all. Not everyone shared that opinion; but it wasn’t just one person, it was a disturbing common theme, and it is not the first time I’ve heard it.

I want to say something to these AppSec experts that think quick and shallow is good enough. AppSec experts who in trying to serve their developer customers might say “at least it’s not nothing”. A customer is “one that purchases a commodity or service” (Merriam-Webster). Your developers are not your customers, we are. Your developers are not the ones using your product and paying your company for your service, we are. The developers are your partners and producing secured applications is your joint responsibility. The recent highly visible breaches should have shown you that. Listen to your real customers, they are complaining that companies don’t care about protecting their personal data. Lately I’ve started to agree with them.

DevOps is here, it is a fact, and it really should be considered an opportunity to engage developers with security in early stages. But not the way many do it today. If you want this to work, respect your developers. Don’t be afraid of them. Stop treating them as spoiled children who would not let you in unless you agree to play by their rules. Most developers are smart and responsible, and care about the quality of their work and contribution to the success of their company. Treat them as such and it will pay off in the long run. They don’t want to complete tasks just to check a box. They want to do things that matter. Let them do security that matters. Developers hate going back to fix old defects. They hate going back to patch security flaws. Lowering the security scanning standards increases the chance that a pen testing activity run months later will detect security vulnerabilities that could have – and should have – been identified and fixed before.

Finding the middle ground

Like in many other cases, the solution here is in finding the middle ground. Work together with your architects and development leads. Try to get to a workable compromise. Be honest. Tell them what the tools can and cannot do. Be clear about the value they get from basic operations and what the value they can get if they tune up their practices. Figure out, together, what would be the cost of that tune up. Only by understanding what’s being missed, will you be able to have a responsible discussion about the risk you are exposed to and the one you are willing to accept. Once you get that agreement, present it to the executive level and make sure they understand the business impact of adopting the change and the risk of not changing. Who knows? You may be surprised to learn that developers are responsible grownups who care about the security of their products. You may also learn that while your executives want to speed up time to market, they may not be willing to accept corner-cutting that puts them at a higher risk of breach.

I expect that many AppSec experts and dev leads will disagree with the above and may dismiss it as a rant. Some might say that the only reason I am writing this is that my tool can’t offer this experience. Others will say that the development world has changed and the AppSec industry had to change with it. That old school approach doesn’t fit the DevOps days and that I need to accept the new way. Maybe I’m old. The bottom line is that being your customer, I trust you with my personal information. Please protect it. Don’t you want the same for yourself.