The rise of DevSecOps

All too often security is retrofitted onto a product release at the end of the development cycle. DevSecOps aims to tackle that without slowing down the process.

By Jo Best

Tue 29 May 2018 @ 12:25

For any technology professional, from the helpdesk assistant to the CIO, improving security has always been at the top of their list of priorities. Over the last couple of years, however, a stream of high-profile data breaches and security failures at large corporates has served to raise cybersecurity to a board-level issue. Now, once again, companies are looking to make sure that good security hygiene is undeniably the responsibility of every member of staff – and they’re turning to DevSecOps to help them do it.

The concept of DevSecOps was reportedly created by Gartner analysts back in 2012, but it has taken until this year for the idea to gain significant traction. Now, the analyst company is predicting that DevSecOps will be embedded in 80 per cent of rapid development teams by 2021.

DevSecOps, as its name suggests, is a branch of DevOps, the software development methodology that allows companies to continuously create, test and rollout new iterations of code by integrating development and operations teams. DevSecOps aims to build good security practice into the software development workflow, by adding security professionals into the development-meets-operations mix.

It's a common complaint that product security often runs behind the pace of product development, with code ready to hit the market before security professionals can sign off that it’s watertight. Thanks to the increased speed of releases that DevOps enables, it's a problem that product teams are now running up against more frequently. Security is still too often something that is bolted on to a product or release once it's completed, rather than an issue that is revisited consistently throughout the product-creation lifecycle to help shape development.

DevSecOps is the industry's attempt to deal with the issue by making sure security is inescapably baked into the product development process.

DevSecOps covers a number of principles that security staff should adopt in order to ensure more secure software products. These include using data science, adopting proactive security monitoring and shared threat intelligence. Security staff, one recent DevSecOps manifesto states, should be actively involved in solving security issues thrown up in the development process, rather than simply identifying them and leaving them for developers to fix.

Approaches to DevSecOps vary between companies and practitioners, but there are some common ideas. DevSecOps discussions often touch on the idea of 'moving security left'; that is, bringing security into the software development process at an earlier point, rather than simply addressing it at its conclusion. If security is a priority when software is being built, not just when it’s being released, companies are likely to end up with completed products that don’t need IT teams to retrofit security before they can hit the market.

Another of the recurring DevSecOps principles is increasing the use of security automation. Automated security practices stand a greater chance of fitting into the DevOps workflow: they can be run in the background with off-the-shelf tools, and so are harder to ignore or forget than similar testing processes that need manual oversight. Automated security can be used for pre-release testing or after-release monitoring, and work to secure new code without slowing down the development cycle.

And, like DevOps, DevSecOps stands or falls on a company's ability to build cross-functional teams: teams that involve not only development and operations, but now security professionals too.

While not every member of staff is likely to have a full complement of dev, ops, and security skills, all teams should aim to. Installing a security champion is one way to drive the agenda forward: security champions are members of other teams that are sufficiently up to speed with security issues, but not necessarily from a pure security background. Their job is to recognise the points at which it’s a good idea to call in the security experts to help out with thorny problems.