DevSecOps

Davey Winder explains how software development teams can benefit from a culture of security

Even by normal IT jargon standards, “DevSecOps” sounds pretty impenetrable. What gives?

Well, you may have already heard of DevOps. Short for “development and operations”, it’s an idea that aims to streamline software development through tight integration between the teams that create the code and those who deploy and manage it.

No surprise, then, that DevSecOps is DevOps with security added in. The DevSecOps mindset calls for security to be a core consideration throughout the development process, rather than something that’s left to specialists and only tested at the end phase. If your business has an in-house development team, it’s an evolution that’s well worth pursuing.

Shouldn’t developers already be thinking about security?

You’d certainly hope so, wouldn’t you? However, the DevOps mantra is all about delivering applications at high velocity and minimum cost, and security concerns tend to pull in the opposite direction on both fronts. No surprise they often get sidelined, or relegated to a retrospective exercise in box-ticking.

DevSecOps seeks to ensure that security is built into every stage of development and deployment, by cementing secure thinking into the framework itself. It thus becomes the responsibility of the many and not the few – and more eyes means better security.

So we’re talking about a complete change of mindset for both development and operational teams?

It doesn’t have to be that drastic. DevOps is already founded on understanding and collaboration across different functions, so it’s not a huge step to add one more perspective into the mix. Ideally, security should quickly become just another part of the process. Gartner, in a recent report, neatly suggested that the goal should be to make “the Sec in DevSecOps silent”. And this isn’t as difficult to achieve as you might imagine: the key, as with so much of DevOps, is automation.

Surely trying to automate security processes is asking for trouble?

Not necessarily. When you think about it, most businesses already rely to a large degree on automated security testing and tools to protect their systems and data. There are plenty of similar automated tools for testing code functionality, so that holes and potential exploits can be identified and flagged up long before a project hits the production stage – helping to minimise the impact on costs and schedules. Automation can help towards the end of the process too, by using scripted tools to analyse and attack a deployment candidate running on a virtual machine.

So will DevSecOps allow us to lay off our in-house security staff?

In a sense, it will greatly increase the size of your security team, by bringing everyone involved in DevOps into it. Of course, you can’t really train every developer to be a security specialist, but given the right tools and the right mindset, security vulnerabilities become just another bug that needs to be detected and corrected.

And how costly will it be to adopt this new philosophy?

There’s a cost in moving to any DevOps system, but progressing from there to a fully integrated DevSecOps model shouldn’t be a major upheaval. Most medium-sized businesses will already have the requisite security expertise on hand, and the automated tools don’t have to be expensive: there are plenty of open-source packages that are tailormade to promote a secure software development lifecycle.

“Given the right mindset, security vulnerabilities become just another bug that needs to be detected and corrected”