Every software team can have its own unique set of challenges to solve, be it technical or cultural. Before we dive into the specifics of DevSecOps, let’s try to understand what led to the need for an iteration of existing DevOps methodologies. Along the way, we will discuss why security can sometimes be seen as a resistive effort, instead of a positive push to continuous application delivery. In my experience working with different teams, there are four main patterns that I have commonly observed to be the root cause of this slow-down:

• Lack of ownership

• Last step in software delivery

• The rapid evolution of application architectures

• Outdated security tools

Let’s look at each of these in detail.

Lack of ownership

Often, developers and operation team members don’t feel responsible for the security posture of their applications. Being on the other side of the spectrum, which involves building new features and rolling them out on production, they see security as something that hinders growth. The security adherence is left to a professional that sits in another room.

Unless this becomes a shared responsibility and the team members start contributing to identifying and fixing issues collaboratively, security will continue to be a show-stopper. The entire software delivery process is going to be as fast as the weakest link in the chain – and we don’t want security to be there. Furthermore, it’s important to highlight that adopting DevOps comes with security as a recurring theme in everything that you do, to give you immediate benefit.

Last step in software delivery

In the previous chapters, we discussed quite a few things around infrastructure automation, application delivery, and how we can optimize most of these tasks by adopting DevOps methodologies. However, a critical step in the software release cycles that we haven’t discussed enough is security. The problem is not with the criticality that slows down the teams – it’s more to do with it being the last step.

Traditionally, software teams developed features with a waterfall model approach and pushed them over the fence to the security team, close to the go-live date. These mammoth releases make it very difficult to accurately identify all the security risks that the new code opens up the application to. Manual testing takes time and eventually, all of this leads to a divergence between the pace at which software is developed, and the pace at which it is released. As a DevSecOps practitioner, you should always keep an eye on such bottlenecks as they can slow down your team, resulting in frustration, delays, and reduced confidence. But what exactly makes security audits slow?