Striking the DevSecOps automation-manual balance

Past the waterfall

In the past, developers would bring an idea to life through a series of linear steps; from planning and design, to architecture and maintenance. Each step carefully led to the next in a traditional waterfall model. Once complete, developers would assess the software for operational issues and repeat the whole process again to achieve a more refined product. 

Following such a process meant software was typically released on a bi-yearly basis, or longer. In today’s fast-paced digital world, this model was bound to be out-grown. That is, it metamorphosed into what we now understand to be the DevOps model.  

DevOps transforms the traditional model through eradicating siloes and encouraging greater communication between the software developers and operations teams. In other words, quality checks on the code is evaluated throughout the development life cycle as opposed to at the end. As a result, software releases now occur bi-weekly, weekly or even on a daily basis. Unfortunately, application security models find themselves lagging behind. Two-week long pen tests are no longer feasible when software is issued in half the time. As such, application security urgently needs to adapt.

Organisations need reliable and effective security assurance; they need it to be automated.

Introducing automation 

Now that the development and operations teams have found synergy, we need to bring application security teams into the fold too. Automation is pivotal in facilitating this as it can improve the speed and agility of the security process. 

Through embedding application security testing tools that are triggered at appropriate points in the development cycle or following certain actions, defects in the code can be swiftly detected; making it less costly to correct as well. These pre-configured checks ensure that any and all code going through the automated pipeline undergoes inspection and consistently meets a certain security standard.

What’s more, automation can offer flexibility when assessing various code changes. For instance, in the case that a change is as trivial as a modification in logo colour, excessive security scanning might be interchanged for moderate or no security activities. Rather, stringent checks can be reserved for alterations that involve significant code changes, changes in the application’s attack surface or the addition of a new asset or security control.

Put another way, this method forgoes the static method of testing for one that dynamically moves alongside the development process. Developers can gain insight into their code in real time, as it is built. This is beneficial for a number of reasons, not least that it allows developers to better manage any vulnerabilities or issues that arise. With the code at the forefront of their minds and having a clearer understanding of the code’s context, developers can more readily address the problem.

On the whole, with more intelligent automation implemented, it becomes far easier to conduct open source validation, container scanning, QA testing, API security etc.

Knowing when to slow down

With that said, speed is not necessarily the end goal when automating security. At times, it is wise to slow the process down to run all security activities. It is one thing to change the colour of a logo or the font on an application, and a completely different story when a function deals primarily with customer data. While automation is useful, it can also under- or over- estimate the importance of certain findings; resulting in false positives. With the latter case being decidedly riskier, it would be better handled manually as a human can make sense of that information as well as make a better judgement call.

At the end of the day, each software release has its own set of risks and levels of severity. It is up to the development teams to accommodate these differences accordingly.

DevSecOps at a crossroads

DevOps organisations often find themselves at a crossroads. They have the choice between what might be termed the ‘security express lane’ and the ‘security slow lane’. The security express lane would see automation override every aspect of the DevSecOps process. However, such an approach fails to recognise that there is no ‘one-size-fits-all’ solution; particularly as every company and every team works differently, as well as faces their own unique sets of challenges. In one enterprise alone, there could be hundreds of development teams. As such, those who take this path would do well to take on-board a security advocate who can counsel teams on remediating any issues and ensure that security needs are met.

Organisations that opt to take the slow lane do not have to be confined to a lengthy pace either and can be supported to go fast when and should developers choose to do so. These developers can simply decide to utilise the security tools that work best for them.

Ultimately, it is not a question of whether automation or the manual process is better than the other, but how software development teams can integrate and balance these two to meet our needs for quickly developed and securely built software.