Putting the 'Secs' into DevOps

We have already examined the ‘phenomena’ that is DevOps and asked what it really means, how it really works and how to tame this new beast here on Computer Weekly.

Matthew Pendlebury, a senior security consultant at MWR InfoSecurity thinks that there’s not enough Sec (security) in DevOps. Indeed, he feels there’s a pressing need for DevOps to become DevSecOps… or at least for DevOps to gain a better grasp of Sec.

Making secs sexy to DevOps

Some developers may have little prior experience of security suggests Pendlebury.

In others… in some organisations, teams that focus exclusively on software may have also acquired the responsibility for designing and running the infrastructure on which their code is deployed, which again requires a different skillset which they may have to learn and again contains many implications for security.

“Software security activities are spread throughout the development lifecycle and this is no different with DevOps. Security starts as a set of requirements that need to be satisfied and in many cases these can be tested by code. DevOps has a strong focus on using CI/CD for performing testing and validation activities. This compressed lifecycle leaves little time in for conventional manual testing of routine deployments, for either quality or security purposes, so testing is heavily automated,” asserts Pendlebury.

Using this phase for security testing offers several benefits. DevOps usually relies on virtualisation, so testing can happen in truly representative environments.

Expressing the results from previous (manual) pen tests as code can detect regressions.

Also, test cases can invoke automated tools that perform vulnerability analysis on the entire environment before deployment. Additionally code quality tools such as static analysis can be invoked here and decreases in code quality can fail builds.

Pendlebury continues, “Automated security testing is an effective approach to accelerate development, however it is not a silver bullet, and security still needs to be considered throughout the software lifecycle. It still holds that the earlier that a security problem is recognised, the quicker and cheaper it is to remedy.  In DevOps teams as well as conventional development models the usual approaches to this are to educate developers about the security domain, give them techniques they can use such as threat modelling and embed knowledgeable security champions into teams to provide depth.”

For Pendlebury, the problem (or the particular challenge) here is that DevOps approaches can have an over-dependence on the tooling — and this may lead to developers not using their own awareness to identify security issues specific to their product.  Tooling will not necessarily identify all the specifics of the solution being developed and will also lag behind new issues being discovered in the wild.

“There is already a growing movement called DevSecOps which seeks to push the agenda of security in a developer operations environment.  It may be that the more established DevOps term gradually absorbs security considerations, indeed vendors such as Puppet are actively pushing this.  Whichever term dominates, pushing security into DevOps processes is clearly the future,” he concludes.

MWR InfoSecurity provides specialist advice and solutions in all areas of security, from professional and managed services, through to developing commercial and open source security tools.

Image Source: Comedy.co.uk

Image Source: Comedy.co.uk