Securing software: Why we're all coders now

DevSecOps may be a clunky label but it can help start a necessary conversation, says Christian Beedgen of Sumo Logic

Most people agree that security should be integrated into the software production pipeline at the start.

"Anything which helps reduce the chances of vulnerabilities occurring in shipping code has to be a good thing," said security consultant Graham Cluley. "Not just for customers, but also
for the companies developing the code who won't find themselves in the unpleasant position incurring system downtime, or having to drop everything to fix a serious security hole at high speed."

However, very few organisations are actually doing it. A recent Computing survey of IT professionals on the DevOps journey found that only five percent had implemented DevSecOps. Which raises the question, why?

Christian Beedgen, CTO at Sumo Logic, views the slow take up as the result of the time taken for the art of coding to percolate through to other domains.

Previous generations of software tended to be primarily produced for distribution on a DVD or similar, he pointed out. On receipt of the DVD, the customer's operations staff were responsible for getting it working properly in their environment. But once software moved to the web with smaller apps and frequent updates, that work became the responsibility of the producer. Add the fact that more companies started producing their own software and the direction of travel became clear. Ops needed to learn to code.

"My personal hypothesis is that the people who will survive in technical roles will have to be programmers," Beedgen said. "Basically there are two kinds of people in the world: those who know how to program and those who don't.

"Ops people have to expand from writing one-line shell scripts to using Python or whatever. They have to start learning languages and declarative configuration that is actually expressed in the language itself. If I'm an Ops guy who is mostly busy watching a bunch of switches and giving cute names to three servers I won't really have a job anymore."

They'd rather burn the building down then commit to something new-fangled like DevSecOps

This principle is working its way through operations but it must move on to security, a group that has so far proved a tougher nut to crack.

"You have a bunch of security people who have a process-focused,

old-school risk management mindset. They'd rather burn the building down then commit to something new-fangled like DevSecOps," Beedgen said. "There's a big culture clash there."

What makes things difficult is that the cultural shift is rather one-sided. Security guys need to learn about code more than coders need to learn about security. So is the issue that security folks are defensive, outnumbered and outgunned by the developers who control the narrative?

"Maybe but I don't think the solution is to hire as many security guys as developers, it's about embedding the folks with the right mindset. If they're already programmers they'll be able to talk to other programmers," he said.

One way forward would be to give security coders a higher status. While hardly a typical organisation Google may show the way in this regard.

"They have what they call an SRE or site reliability engineer. I've seen people with PhD in computer science systems going straight there. There's no stigma in being in that sort of Ops role. The same will happen with security too. So eventually you'll just have a pool of developers and some of them will worry more about the aspects of writing code, some about the security and some about deployment."

DevOps is an evolving process which is realy part of a wider philosophy. Beedgen said he doubts that the "Nirvana of DevOps" really exists on the ground as a practical reality, but that nevertheless, that label is valuable as a flag to aim for.

"The VP of Ops becomes the VP of DevOps but I think the divide still exists. It's the same with security. If the DevSecOps label helps people discuss this kind of stuff maybe it will bring down the walls, reorganising from functional to project-orientated work which is what this is really about."